Yes, I like my hobby, and also the possibility of working in any major city. But if we are drinking together, would you consider not asking me about this shit? I'm quite capable of rambling on and on about it as you see below, but I don't particularly enjoy doing so.
Worse, some people give the impression of thinking the purpose of my life to make a mark upon the world, through really excellent system administration I suppose. Someone who thinks that might also think the number of my words here must have something to do with how deeply I care about computing machines and their efficient purchase and operation. Well, it doesn't. Got it? GOT IT?
Ok. There are five sections:
At best, I've found people usually read about a third of an article, then post a link to it from their blog saying ``He has some good points.'' It's hard to get through an entire rant. There's still something wrong with my writing style. Sorry for that.
They're expensive, but you can either just pay, or you can get them used on eBay, especially if you can find yourself some ExtremeWarez or IOS imagez to upgrade them without having a service contract. :)
The biggest problem with L3 switches is their fans. They're fucking noisy. Can someone trick up a watercooling mod for an Alpine 3808? That would please me immensely.
And I've become sad and disappointed.
NetBSD themselves, the first free Unix to deliver a useable Scheduler Activations, has retreated, too. They state most prominently this reason: they never finished their implementation enough to work on SMP machines (much less NUMA :) ). The real reason seems to be about the same as Sun's, in that implementation complexity drove their ultimate decision. If they'd started with Unstable Threads, maybe they wouldn't have had to rip it out! We'll never know.
This was originally part of my position on DSL vs. cable, but I now believe that there is only a weak relationship between the two issues.
This is why I think the anti-trust case against Microsoft is moot. With competing technologies like Java in the pipe, they don't have a chance. Some day, we'll all be using the same kind of computer, the Java Computer! HOO-ray.
There are still two ideas left in this rant that might be kind of interesting. First, the Bluetooth ``slate'' idea, which is something like the eBook reader Josh showed me that turns completely off when you shut it, but this one connects to your always-on celfone. It doesn't run any programs itself, just gives you a bigger screen and a two-handed keyboard for interacting with programs on the celfone. The programs are required to re-render themselves onto the celfone screen without losing your place if the ``slate'' is shut off or runs out of battery.
And second that futuristic celfone applications ought to borrow user interface metaphors from webapps like Gmail and Facebook, and from emacs programs like Gnus, not from Windows 95 like some of them do now. Maybe we shouldn't think so much about the celfone's small screen and keyboard, and instead think (1) it's always-on and emphatically single-user and expected to never crash, all unlike laptops and desktops, and (2) it's virgin territory, where we can implement a completely new platform---because the screen and keyboard are small people won't think to fuss and whine when it doesn't look exactly like their laptops. They haven't even learned yet to whine when theirs doesn't look exactly like their friend's celfone, which gives us a droolably fantastic chance to invent some truly new and creative designs, and change the way people think.
There is a $0 version for Mac OS. If you have VirtualBox hosting Windows inside a Mac OS machine, maybe you would like to power off the guest and mount its NTFS disks using MacFUSE. This shows how.
BTW there is also a Solaris Nevada version of VirtualBox which I also use and like. I can't get RDP to work, though.
so, there is the trick for case-sensitive booting on PPC. I've been warned on the Internets that case-sensitivity breaks MS Word (seems ok so far) and Adobe CS3 (haven't tried it), so watch out.
The network has a lot of neat features that are useful most of the time but make it somewhat fragile and hard to upgrade. It has dynamic routing: BGP for the exterior routes and OSPF internally. We don't have an ASN---IPv4 BGP is mostly just an exercise, while IPv6 BGP is actually doing stuff. The network has IPv6 everywhere, and we have a fast tunnel to an experimental non-commercial network with diverse peerings. It deliberately uses hubs instead of switches. Some segments have an experimental arpless hack to resist ettercap. And upstream and downstream traffic is queued and conditioned by HFSC.
The diagram is way out-of-date. I have more machines, and others have fewer. We are using iSCSI, which means gigabit ethernet and switches, no more hubs. We use a lot of fiber, because for older equipment, fiber gigabit ethernet is cheaper than copper, and because we have equipment on the roof (not much yet, just one PeeCee). The switches are L3, so the main router now has only two Ethernet interfaces: one is a /30 link to the switch, and the other is for port monitoring. Those eight tulip ports worked very poorly---the thing could seriously only handle like 60kpps.
ping
<hostname> guest's laptops.
I don't know if this makes sense, but you know, everyone has their own pet regional cabling style. Just look at the superior electrical wiring used in European buildings compared to the solid-core wire and daisy-chained circuits that Americans use.
Mine is a sort of ``third-world HAM radio operator'' style. I try to converge on two kinds of cable for everything---RJ12 and RJ45, both over solid-core CAT5---and make short pigtails converting between strangely-shaped connectors and these two. I've been pairing inner conductors with their overall-shield, and this seems to work fairly well for Maple Bus and PeeCee keyboards. I don't really understand baluns or RFI, but you can't tell me that my pigtails won't work because they do. Unfortunately, I am stuck with three kinds of cable instead of two because the pattern of assigning CAT5 pairs to RJ12 pins differs between telco/LocalTalk and my serial and Maple Bus pigtails.
Summary:
Posts:
There are a lot of claims about logging or journaling filesystems of various kinds being able to fsck quickly, or needing no fsck at all, or never losing data, but given the amount of regression testing these open source developers do and the low quality of the equipment with which they're forced to work (IDE with unpredictable write caching, which as you can see the guy's patch tries to work around, and IDE's habit of auto-downgrading to slower speeds, dropping past the minimum speed where the hardware does CRC checking, and then writing corrupt data over good data), it shouldn't come as a surprise these claims are often lies.
This guy performs a test that's brilliant in its simplicity: he boots up a Linux box, makes its filesystem busy with write activity, and then pulls the cord. Some of the so-called journaling filesystems he tried soon became so corrupted they wouldn't boot up---the autocheck demanded user intervention.
His experience agrees with mine using VxFS on HP-UX 10.20 and LFS on NetBSD. My experience with both of those two is, they are bug-ridden, and the O(n) fsck is a fiction because they all have an O(n^2) supercarefulfsck mode that you need to use all the time after a crash, or else your system will crash again due to lingering filesystem corruption. I like the cord-yanking test a lot, and am sick of having these bogus vendor/zealot claims parroted at me, so now I parrot this mailing list post back at them whenever I can.
I don't know if you realize this, but mailers like Postfix command the kernel to commit certain things to disk synchronously, and to tell Postfix after they've been written. Proper Unix kernels are expected to do this without lying, even when NFS is involved. If Unix keeps to its architecture, the overall Postfix MTA will not lose any mail, no matter how busy it is, no matter when you pull the cord. But with this half-journaling stuff that makes integrity claims you later find are untrue, and this sloppy Windows95-grade IDE write caching, I think it's unlikely the promises Sendmail kept in the days of SunOS 4.1.3 are still kept by Linux MTA's today.
I need to write another rant about how people overestimate the benefit of RAID some day soon. The short version is: the times I've seen people disastrously lose data recently are not plain old disk failures. They're bugs in the filesystem implementation itself that cause corruption, or they're issues with IDE (yes, always IDE, never anything else) where there is no way for the host to know whether block <n> was successfully written to the disk or not because the bus just becomes confused and muddled, or where one failing/confused drive interferes with its partner ``Master'' or ``Slave'' on the same bus so it's difficult to isolate which drive is really bad, and where it's not even a matter of data being written or not written and the host knowing whether it was or wasn't, but rather corrupt data is written, often either without an error, or for the pedantic yes it is with an error, but with an so-called ``error'' that sometimes occurs during normal operation. When faced with these three classes of problems. RAID will mess up, and these are unfortunately the most common and realistic problems people have with homebuilt PeeCee IDE crap. People don't realize how dependent RAID is on accurate error reporting, no silently writing corrupt data, and the same sorts of synchronous/atmoic writes that journaled filesystems need. They think it's like TCP and will just magically filter out bad disks like dropped packets. Not only does RAID just not work that way (Something went wrong so you couldn't write to one of the two RAID1 disks. Then you lost power. How do you know which mirror is the good one?) but it doesn't protect you from broken so-called ``journaling'' filesystems that go into fsck convulsions when you pull the cord.
I've also heard at least two stories about entire RAID sets that were lost because the ``hardware RAID'' PCI controller card went nuts from ``a bad SODIMM'' or something and wrote garbage over the disk, or worked fine until a disk failed and then couldn't recover the set, or the guy doesn't know exactly what happened but after being down for two days struggling with it had to throw out the card and go to backup tapes. Yet everyone still tells me how hardware RAID is the only serious RAID, and ``software RAID'' is junk, as if all RAID weren't done in software. It's amazing how successful marketing is at controlling people's minds even when opposed by glaringly contradictory facts about painful disasters.
so, I favour a plain old 'tar' or 'rsync' backup onto a second separate disk, or an AFS mirror, or something like that. It would be good to think about what happens if you accidentally delete a bunch of stuff, too. Even just being able to roll back 24 hours could be worth a lot, if you have old college photos and emails and source code that you'd like to keep into your retirement, and RAID won't give you that. Running rsync at 4am from one local disk to another kindasorta will, though of course I'd rather have Netapp snapshots.
Netapp is allowed to do RAID. Netapp's filesystem fsck's in O(n). I believe their marketing. It's just yours and that of all the products you like that I distrust.
POSTED: ye who spits on this square of the sidewalk consigns himself and all his descendants to work as a slave to Scrooge McDuck for all eternity!
Citizens must be free to negotiate contracts without government interference, huh? There's this simple-minded faith-based belief in an ordered, comprehensible universe behind this Libertarian scum. I don't buy it. I like this a bit more:
free markets are always constructed by political regimes. I think this is true in the nineteenth century hayday of the ideology of free market, and that this is equally true in our contemporary neoliberal phase,
-- Michael Hardt
It's not ``government invasion into the ability of `private parties' to `consentually' form arbitrary contracts between one another.'' The government is the one enforcing these contracts. Contract law is not an empty field. There are already restrictions on what kinds of contracts are enforceable. I think the set of restrictions should change. Drastically.
In what way, you might ask. I'd like a contract regime that promotes something like a vibrant free market, which, as Hardt said, is ``constructed'' by government, to whatever extent it exists, today just as it was in the ninteenth century. In the regime we have now, there is no contract shopping---unless the transaction involves thousands of dollars (and sometimes even when it does), people just blindly agree to everything. The shoppers can't understand the contracts. They can't get easy access to the contracts to compare them, because they're always brought out at the last moment, right before money changes hands, or whenever possible even after money changes hands (oh, sure, we'll give you a refund). Once they can set up the first two factors and trap the majority of customers into blindly agreeing, sellers all begin to offer the same set of exploitive terms---the price premium you can charge for having a customer-favorable contract is nearly zero, not because it's worth zero but because it's unshoppable. It's not a vibrant market with plenty of contracts to choose from, as-is. Even contract expert legal geeks just agree to whatever PayPal wants, because the alternative is overwhelmingly expensive. The current consumer contract landscape is one of rigid cartels in which anyone with market share becomes a de facto legislator.
Most of these agreements should be simply wiped out, and the seller should have to contend with whatever legal exposure he has from ``I sell something, and you buy it.'' Is this exposure too great? Alter the law, for everyone, to reduce the seller's exposure, in a way we all find reasonable. I understand that some businesses selling inexpensive things have too much legal exposure without all their click-through fine-print. The Europeans who come over here visiting actually seem more afraid they're going to get sued than they are afraid of getting mugged. I'm not exaggerating! In that sense, they share the business's perspective.
But the right way to relieve this exposure and keep open these markets for cheap services is to adjust the law for everyone, through democratic legislative process, not allow companies to form private legislative branches and gather unto their bosoms hoardes of opt-in citizens without, let's be honest, meaningful free market process, much less democratic process.
If I want to feel like I'm living in a democracy, that means I want a stake in making the rules that govern my daily life. Having to be careful what I send to any @hotmail.com address doesn't give me that feeling.
The CVSup FAQ says it more artfully than I do, but just in case we read it differently let me spell out my interpretation in a literal way. I think the CVSup guys are right in pointing out that this objection comes mostly from just not wanting to deal with any language but C. A performant language with rich libraries is hard to achieve and maintain, whether it be C or any other language. That's however not a good reason to preempt all work on any language except C. Such a position is a dangerous pruning of human inquiry.
For the performance objections, you need to see the Java, Language of Tomorrow rant. ``Interpreted'' is an arguably useful label, but it has no fundamental basis---there are only fast language environments and slow ones.
It's also outdated, mostly, which is why I have to pull it from archive.org. Third time's the charm, apparently. Linux's third-generation SCSI generic framework is finally ioctl()-based, just like the one on BSD and Solaris has been since the beginning.
Anyway, his old opinion is backed up by more experience than most. On the other hand, doing all that rework ten times over for Unixes that he doesn't even use himself must get annoying. He has this pet <bus>,<id>,<lun> device addressing scheme that he seems to think is some kind of ueberspecifier, transcending that pathetic ability to refer to devices with filenames which Unix already includes. Thanks to his invention, we can use easy-to-remember triple-sets of numbers instead of linguistic mnemonics! What's next, virtual dip switches? He tries to emulate this pet scheme on all platforms. Personally, I think it's colossally stupid. First, how does it make my life easier that I must remember to use 'cdrecord dev=0,6,0' and 'eject cd0'? I now have two specifiers to remember instead of one. This is almost as bad as Linux's ``generic driver'' practice of attaching the same SCSI device with multiple drivers. Second, his ueberscheme is not entertainingly clever enough that I should put up with it: how do I know which is the ``first'' SCSI bus, and which is the ``zeroth''? Bus-numbering is not well-defined, particularly when some of the SCSI busses are not SCSI, but rather are IDE, or dynamically-attached 'umass(4)' USB devices. If he dithers over this, toss him a fibre channel WWN, and I'm sure he'll feel obligated to include that 16-digit hex number in his ueberspecifier, because it feels so official to him.
In his critique, he equates the brokenness of Linux, which corrupts diagnostic messages from devices and thus makes it impossible to do any 'cdrecord' development work on Linux, with the brokenness of BSD, which interferes with his pet device-addressing scheme.
The ethics of BSD require that, when someone says, ``how can I do <foolish thing>,'' we must respond with ``you can't'' as often as is practically convenient. BSD forces Joerg to abandon his pet naming scheme and use the same damned device names as the rest of the system. This is a feature, not a bug.
So, yes, I'm criticizing the criticizer. Read Joerg's article, and listen to him when he criticizes Linux, but ignore his criticisms of BSD. K? No, seriously!
