with 'linux' tag

stable and well-understood technologies

AddyOsmani.com - Stick to boring architecture for as long as possible

Prioritize delivering value by initially leaning on stable and well-understood technologies.

i appreciate this sentiment. it is a little funny to me that what i can claim the most expertise in would probably be considered some of the most stable and well-understood technologies out there right now, but i have been working with them since they were neither. perhaps i have crossed from where as long as possible becomes too long, at least as far as employability is concerned.

a related tweet from maciej ceglowski.

installing linux before distributions

i am not sure what triggered it, but i started diving into the public record of my early involvement with linux via the usenet archives on google and collection at oldlinux.org, particularly the archives of the old linux-activists email list.

the first version of the linux kernel that i was able to run was 0.11. (the 0.10 kernel wouldn’t run on my machine because i still just had a monochrome monitor and mga video card.) at the time, the release consisted of two floppy disk images. the “boot” image went in first and was the linux kernel. once the kernel was loaded, you had to pop in the “root” image which had a basic collection of utilities that you could use to install the system.

there was no networking support in the kernel yet, so “installing” to a hard drive basically consisted of setting up a couple of partitions for the kernel and root disk, and copying things into place. there was a utility called “mtools” that could read DOS-formatted disks or partitions, but what i often did was just dump tar files to a floppy from DOS and read them back after rebooting into my linux partition. eventually you could bootstrap your way into having some sort of serial communications so you could use a modem to dial out and transfer files with something fancy like kermit. (i think we had hardwired serial connections in our dorm rooms at harvey mudd college when i first started working with linux.)

at the time, there were no other distributions. gcc had been ported and you could download the binaries and then start compiling anything else you could find. people would upload things they had compiled to tsx-11.mit.edu and nic.funet.fi, the two hubs of linux distribution. my first mail to the linux-activists list was saying that i had ported unzip and zoo and some other things to linux. (which probably did not involve much porting, really.)

i don’t have records of how this happened, but somehow i volunteered to take over maintenance of the “root” image from linus, and so the official release of linux 0.95 was a boot disk (kernel) from linus and a root disk from me. there was an INSTALL shell script which you could use to get things set up on a hard drive partition. we did a couple of releases that way, and then distributions kind of rapidly filled the space, starting with mcc interim linux.

what is fair?

Distribution Service

Linux has been written entirely by volunteers who have been working on their own time, and I don't think that should change. I also don't think it's fair that someone take what has been written for free by people and try and sell it to turn a buck (i.e. make a living doing so). How fair is that to those of us who contribute our time freely?

i am not sure when it shifted, if it was gradual or sudden, but i do not agree with what i wrote back then (1992!) about the fairness of someone building a business on what someone else has given freely. that has always been a central tension in what became known as the open source community, and you even see it coming up in current discussions about the training data used by generative “AI” systems.

(also, another quote: “I cannot see Linux being a full-time thing for anyone at this point, really.” oops!)

bug tracking and code review

i was going to write some reactions to an observation that postgresql has no bug tracker and its discussion last week, but lost the spark and abandoned the post after a few days. but today i ran across a quote from linus torvalds that neatly sums up my thoughts:

We’ve always had some pending/unresolved issues, and I think that as our tracking gets better, there’s likely to be more of them. A number of bug-reports are either hard to reproduce (often including from the reporter) or end up without updates etc.

before there was a bug tracking system for mysql, there was a claim that all bugs were fixed in each release (or documented), and there has been a lot of pain in seeing how well that sort of claim stacks up against a actual growing repository of bug reports. if the postgresql project were to adopt a bug-tracking system, i am certain that they would find the same issue. before long, they would be planning bug triage days just like every other project with a bug-tracking system seems destined to do.

another good email from linus about these issues was pointed out by a coworker, but this part in particular caught my eye:

Same goes for “we should all just spend time looking at each others patches and trying to find bugs in them.” That’s not a solution, that’s a drug-induced dream you’re living in. And again, if I want to discuss dreams, I’d rather talk about my purple guy, and the bad things he does to the hedgehog that lives next door.

the procedure at mysql for code reviews is that either two other developers must review the patch, or one of an elite group of developers who are trusted to make single reviews. then the developer can push their changes into their team trees, taking care to have merged the changes correctly in anywhere from one to four versions (4.1 and up).

this is a huge amount of friction, and is one of the most significant problems causing pain for mysql development. two reviewers is just too high of a bar for most patches, and having the rule makes the reviews rote and less useful. there is also an unreasonable amount of distrust being displayed by this procedure, that says that developers can’t be trusted to ask for help when they are unsure, but should feel free to make the occasional mistake by pushing something that isn’t quite right.

i wonder if we could be taking better lessons from linux’s hierarchical development model, with the pulling of code up through lieutenants to a single main repository, rather than the existing model that involves every developer moving their own stones up the pyramid. it would require some developers (more senior ones, presumably) to spend more of their time doing code management as opposed to actual coding.

monty is not particularly happy with the state of development of his brainchild now. would he be happier if he were in a linus-like role of rolling up patches and managing releases?

i wish had the patience to write at less length and greater coherence about this.

going virtual

along with re-thinking how i back things up, i have also been thinking about how to handle hosting my stuff. currently i have a server in a colocation facility that is costing me $75/month. it is a p4/2.4GHz with 768MB of RAM and 55GB of disk space, of which i’m only using about 20GB. the machine is over four years old now, so i am starting to get the creepy feeling that it is running on borrowed time.

for $30/month, paid annually, i could get a virtual server from linode with 384MB of RAM and 18GB of disk. it is half as much memory and even less disk space, but it doesn’t look like the memory will be an issue based on my current usage. i can use less disk-space by archiving things off to other places like amazon’s s3, such as the access logs for this site that go back to 1997.

there are other virtual server providers, of course, but jeff waugh’s praise of linode is what got me started on looking into this again. they look like they have their act together, based on the activity in their forums and how they present themselves in general. so many of the other providers seem so dodgy.

of course, if i do move to a virtual server, i’ll have to figure out what to do with the physical server that i pull out of the colo facility.