Ah, yes. We have (sadly) plenty of experience with these cards; the remaining two we're using are earmarked for removal from our database cluster in favour of software RAID.
However, given that aaccli isn't distributed by FreeBSD, and is in fact a Linux binary only supported through emulation, suggesting that this is something FreeBSD/Scott gleefully accepts seems a bit unfair. At least the driver itself is pretty good; certainly better than the Linux one, ugh.
The Atheros wireless HAL situation seems forced by FCC regulations (and presumably Atheros lawyers). Didums. Buy a different card if it bothers you so much. Heaven forbid FreeBSD give users the choice of actually using the hardware they've got instead of rabidly threatening people who are presumably at least trying. I guess they, like me, are just too easygoing.
if_ndis is pretty nasty too, and it's certainly not something I'm going to want on any of my production machines, but.. well.. just because it's evil doesn't make it an invalid choice;)
10/15kRPM drives aren't just consumer level drives with faster motors; they use physically smaller platters and lower areal densities and higher quality components to reduce seek times and increase reliability. If you take a cheapo 80G platter consumer drive and throw another head assembly on it, you're going to make it even less reliable because of the higher component count, and probably still get beaten in real world performance because while your seek times are on the order of 10-20ms, a good 15kRPM drive can get more like 3ms.
By the time you've switched to higher quality components and testing to make the whole thing worthwhile, and absorbed even more extra costs because you've got such a small target market and lower economies of scale, you'll probably find it makes more sense for said market just to buy more drives to get their multiple independent heads.
"Opera is a great browser for ensuring pages display according to standards compliance, but Firefox has the features, speed, and stability to ensure that the user's browsing experience."
The user's browsing experience what? And what features does it have that Opera is lacking? If anything, I'd say Opera is the one with features on its side, especially out of the box, and I haven't seen any problems with stability or speed, even in beta versions.
SATA's excellent where price, STR and space are more important than seek time; this covers plenty of server applications. A couple of 400G SATA drives in RAID-1 is perfect for a backup/log box, and an appserver or webserver which keeps all its working set in memory really isn't going to care if seeks take 9ms instead of 3. For larger arrays, the larger size of SATA drives saves loads in terms of space, power and heat, not to mention array complexity and raw cost.
Sure, most of our servers are SCSI, but (S)ATA fills an important gap. Not every server's IO, or even performance bound.
Well, I don't know, who is this mysterious "home user" you speak of? If it's my mum, then no; she gets on fine with an old 20G Seagate. If it's me.. well, yeah, kinda. Movies, TV shows, music, games, applications; there's a lot to be said for having all this on live storage, accessable by opening a directory on a network share instead of hunting through piles of DVDs and CDs, only to find the one you want has a scratch, or a hole in it (yay unstable optical media).
If a drive's getting old, or too small to be useful, transfering its contents to another drive is simple; doing the same with a pile of 100 DVDR's isn't quite so trivial. Then there's all the flexibility RAID gives you; bigger drives means you can have more redundancy and still have big-enough logical volumes. What media could be better?
Yup; FreeBSD's ATA driver supports SATA natively, and the chipset-specific code is light enough that it simply doesn't bother with options for you to specify what chipsets you want supporting.
On the other hand, Linux's ATA driver is on the way out, and it's slowly being replaced by the SCSI-based libata (presumably because Linux's SCSI subsystem is the only one with a half-decent API). Both support some of the same chipsets, and some only work with one of them, which can mean mixed results depending on how your kernel is compiled.
"On the CLI, there is no significant delay, but within the GUI (KDE or Gnome) there is a split second delay before things start reacting to user input."
Nope, sorry, I don't see that; FreeBSD's as responsive as any other system I've used, even under load. Unless you're running a debug kernel on a 386 with a software mouse pointer, or have some freakish superhuman reaction times that makes 100fps look like a slide-show, your experience seems somewhat baffling.
If FreeBSD were this slow to service interrupts, things like disk IO and network latency would suffer too; instead I get sub-1ms response times over GigE, and my mouse pointer is smooth as silk.
Funny, when I'm booting Windows, I often find myself wishing it was more like *nix in booting, so I could actually, you know, *see* whatever the hell it does while booting up. Make slow bootups and breakages that bit easier to debug. Given that it's about the most fragile time in any OS, I like a bit of commentary.
"And in the end, you're still dealing with BSD, which is great if you're running a server, but sluggish (response times to system interrupts is slow, compared to Windows and MacOS) when running in a user-centric scenario."
I'm sorry? I run both Linux, FreeBSD and WinXP desktops on a variety of hardware; "sluggish" isn't what I'd call FreeBSD. It plays a mean game of UT2004 too.
Unfortunately it would also introduces the "we have to rewire this room" problem, the "we have to modify all the desks/seats" problem, and the "it all costs 100x more than the crappy IR version and it's *still* buggy" problem (come on, you know it's going to happen). If you're using them for more than anonymous answers you're going to need to let students authenticate too, since they're no longer physically carrying their own device.
No, let's just fire whoever decided IR was a good idea in a huge packed lecture hall and see how cheap we can make RF versions.
It's common to see Accept headers used to determine if a browser is XHTML capable, I've seen sites use it to switch from GIF to PNG, and plenty which use Apache MultiViews to serve files without being explicit about file extensions:/images/bla.{png,gif,svg,jpg} is accessed via/images/bla and it works out what your browser best supports from HTTP_ACCEPT. I expect to see sites migrating images to SVG using this, making even their site graphics fully scalable.
"because it didn't have a "smart" scheduler, the system could still be brought to its knees with busy-loops"
Hmm? Was this a 1.* problem or so? I don't recall ever locking a system up with a busyloop without messing with priorities the way I still can if I have the privileges.
I usually ran Executive, on AmigaOS 3 anyway; anyone remember that and all its MUI dashboard software? It replaced much of the scheduler and made heavy multitasking that bit smoother.
"In fact, in Kickstart/Workbench 2.0 and up, you could do the UNIX trick of specifying an environment variable for your library and font paths so you could have MULTIPLE library and font directories"
Hmmm, could you? I remember doing assign add to attach multiple directories onto LIBS: and FONTS:, not setting env variables.
"In fact, the Amiga environment variable system was implemented as a RAM drive so it could have directory structures."
I used to run an ENV: replacement which implimented an ENVARC: cache rather than blindly copying the whole of ENVARC: into an ENV: ramdisk:)
"The Amiga had its flaws. For example, by chosing the cheaper 680x0 processors, the Amiga never had memory protection or virtual memory which made for some fun crashes."
The flaw wasn't so much in the 68k, which did grow an MMU and was quite happy to virtualize away, but rather the OS, which was designed around a flat address space and lots of implied memory sharing. With the move to PPC it was slowly moving past this design and into something that could be sensibly protected and tracked; I believe MorphOS has full(ish) resource tracking and memory protection?
"The memory allocation code was such a piece of crap"
As with everything, there was software available to mitigate this. Unfortunately I think this class of software was generally ranked somewhat experimental;)
I started work on a bayes filter to detect duplicates articles a few days ago actually, but got sidetracked and it ended up detecting TV show genres from titles. Seriously:
Training the bayes classifier: 4950/5000 (99.00%) Enter a title to classify: Babylon 5
Sci-fi = -5.1525 Enter a title to classify: Simpsons
Cartoons = -3.9344
"I think of... scrolling on the spacebar the name of the song being played in your favourite mp3 player software."
Mmmmm, distracting moving things in my perhiperal vision; just what I need to aid my concentration;)
"I think of... highlighting all keys which function is available for a given program, different combined with SHIFT, CTRL or ALT"
Well, yes, that does seem to be one of the points. Something I can turn on with a spare button just to check would be nice; helps avoid my previous point;)
"I think of... being able to type in the dark because you can see all the keys."
Whenever I decide to give myself eyestrain by being silly and doing that, I can still see my keyboard thanks to my primary display(s). Not that I look at the keyboard much when I type.
And now what, I have to turn off my keyboard at night so I can sleep without having it light up the room? Bah. Give me something that works off reflected light and we'll talk..
Actually, Ruby's quite speedy. It's not the fastest of dynamic languages, but it's certainly on par with PHP/Python in most areas that count. Where it's not, well, that's where the incredibly easy C extension stuff comes in.
mod_fastcgi allows suexec of application servers using the process manager. All the speed of mod_php/perchild hacks and more isolation and portability.
Opera reports itself as "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.01"; this isn't a case of Opera being completely unidentifiable by default. A swift F12-i and Opera reports "Opera/8.01 (Windows NT 5.1; U; en)"
Slashdot Mirror
Ah, yes. We have (sadly) plenty of experience with these cards; the remaining two we're using are earmarked for removal from our database cluster in favour of software RAID.
;)
However, given that aaccli isn't distributed by FreeBSD, and is in fact a Linux binary only supported through emulation, suggesting that this is something FreeBSD/Scott gleefully accepts seems a bit unfair. At least the driver itself is pretty good; certainly better than the Linux one, ugh.
The Atheros wireless HAL situation seems forced by FCC regulations (and presumably Atheros lawyers). Didums. Buy a different card if it bothers you so much. Heaven forbid FreeBSD give users the choice of actually using the hardware they've got instead of rabidly threatening people who are presumably at least trying. I guess they, like me, are just too easygoing.
if_ndis is pretty nasty too, and it's certainly not something I'm going to want on any of my production machines, but.. well.. just because it's evil doesn't make it an invalid choice
WTF are you wibbling about? Where's all the closed source binary-only stuff in my copies of /usr/src? Where's this garbage you speak of?
Unless you qualify your statements, you're just spreading FUD.
Track density is way too high to align more than one head at a time with a single actuator.
10/15kRPM drives aren't just consumer level drives with faster motors; they use physically smaller platters and lower areal densities and higher quality components to reduce seek times and increase reliability. If you take a cheapo 80G platter consumer drive and throw another head assembly on it, you're going to make it even less reliable because of the higher component count, and probably still get beaten in real world performance because while your seek times are on the order of 10-20ms, a good 15kRPM drive can get more like 3ms.
By the time you've switched to higher quality components and testing to make the whole thing worthwhile, and absorbed even more extra costs because you've got such a small target market and lower economies of scale, you'll probably find it makes more sense for said market just to buy more drives to get their multiple independent heads.
"Opera is a great browser for ensuring pages display according to standards compliance, but Firefox has the features, speed, and stability to ensure that the user's browsing experience."
The user's browsing experience what? And what features does it have that Opera is lacking? If anything, I'd say Opera is the one with features on its side, especially out of the box, and I haven't seen any problems with stability or speed, even in beta versions.
SATA's excellent where price, STR and space are more important than seek time; this covers plenty of server applications. A couple of 400G SATA drives in RAID-1 is perfect for a backup/log box, and an appserver or webserver which keeps all its working set in memory really isn't going to care if seeks take 9ms instead of 3. For larger arrays, the larger size of SATA drives saves loads in terms of space, power and heat, not to mention array complexity and raw cost.
Sure, most of our servers are SCSI, but (S)ATA fills an important gap. Not every server's IO, or even performance bound.
Well, I don't know, who is this mysterious "home user" you speak of? If it's my mum, then no; she gets on fine with an old 20G Seagate. If it's me.. well, yeah, kinda. Movies, TV shows, music, games, applications; there's a lot to be said for having all this on live storage, accessable by opening a directory on a network share instead of hunting through piles of DVDs and CDs, only to find the one you want has a scratch, or a hole in it (yay unstable optical media).
If a drive's getting old, or too small to be useful, transfering its contents to another drive is simple; doing the same with a pile of 100 DVDR's isn't quite so trivial. Then there's all the flexibility RAID gives you; bigger drives means you can have more redundancy and still have big-enough logical volumes. What media could be better?
Yup; FreeBSD's ATA driver supports SATA natively, and the chipset-specific code is light enough that it simply doesn't bother with options for you to specify what chipsets you want supporting.
On the other hand, Linux's ATA driver is on the way out, and it's slowly being replaced by the SCSI-based libata (presumably because Linux's SCSI subsystem is the only one with a half-decent API). Both support some of the same chipsets, and some only work with one of them, which can mean mixed results depending on how your kernel is compiled.
Funny, when I'm booting Windows, I often find myself wishing it was more like *nix in booting, so I could actually, you know, *see* whatever the hell it does while booting up. Make slow bootups and breakages that bit easier to debug. Given that it's about the most fragile time in any OS, I like a bit of commentary.
Unfortunately it would also introduces the "we have to rewire this room" problem, the "we have to modify all the desks/seats" problem, and the "it all costs 100x more than the crappy IR version and it's *still* buggy" problem (come on, you know it's going to happen). If you're using them for more than anonymous answers you're going to need to let students authenticate too, since they're no longer physically carrying their own device.
No, let's just fire whoever decided IR was a good idea in a huge packed lecture hall and see how cheap we can make RF versions.
Nitro; another Ruby web framework which seems stronger than Rails in some areas.
Mmmmm, so much choice.
Accept supports providing versions, although I've never seen it used:
/images/bla.{png,gif,svg,jpg} is accessed via /images/bla and it works out what your browser best supports from HTTP_ACCEPT. I expect to see sites migrating images to SVG using this, making even their site graphics fully scalable.
Accept: text/html;level=4, application/xml+xhtml;level=2, text/css;level=2.1
It's common to see Accept headers used to determine if a browser is XHTML capable, I've seen sites use it to switch from GIF to PNG, and plenty which use Apache MultiViews to serve files without being explicit about file extensions:
Use not encouraged? Bwaha
"Instead, Intel has come up with "PXE" which is sort of network boot (will boot from TFTP), but is limited (naturally) to Intel processors."
Um. Did I just dream our Sun X1/T1 PXE environment?
Hmm? Was this a 1.* problem or so? I don't recall ever locking a system up with a busyloop without messing with priorities the way I still can if I have the privileges.
I usually ran Executive, on AmigaOS 3 anyway; anyone remember that and all its MUI dashboard software? It replaced much of the scheduler and made heavy multitasking that bit smoother.
Hmmm, could you? I remember doing assign add to attach multiple directories onto LIBS: and FONTS:, not setting env variables.
I used to run an ENV: replacement which implimented an ENVARC: cache rather than blindly copying the whole of ENVARC: into an ENV: ramdisk
The flaw wasn't so much in the 68k, which did grow an MMU and was quite happy to virtualize away, but rather the OS, which was designed around a flat address space and lots of implied memory sharing. With the move to PPC it was slowly moving past this design and into something that could be sensibly protected and tracked; I believe MorphOS has full(ish) resource tracking and memory protection?
As with everything, there was software available to mitigate this. Unfortunately I think this class of software was generally ranked somewhat experimental
Do you have any plans to support lossless formats like FLAC? I'd be willing to pay extra ;)
"I think of... scrolling on the spacebar the name of the song being played in your favourite mp3 player software."
;)
;)
Mmmmm, distracting moving things in my perhiperal vision; just what I need to aid my concentration
"I think of... highlighting all keys which function is available for a given program, different combined with SHIFT, CTRL or ALT"
Well, yes, that does seem to be one of the points. Something I can turn on with a spare button just to check would be nice; helps avoid my previous point
"I think of... being able to type in the dark because you can see all the keys."
Whenever I decide to give myself eyestrain by being silly and doing that, I can still see my keyboard thanks to my primary display(s). Not that I look at the keyboard much when I type.
And now what, I have to turn off my keyboard at night so I can sleep without having it light up the room? Bah. Give me something that works off reflected light and we'll talk..
Yes, it does. "Opera" and its version number follows its MSIE spoof line (which, ironically, is itself spoofing as Mozilla).
"Ruby is pretty slow at the moment"
Actually, Ruby's quite speedy. It's not the fastest of dynamic languages, but it's certainly on par with PHP/Python in most areas that count. Where it's not, well, that's where the incredibly easy C extension stuff comes in.
mod_fastcgi allows suexec of application servers using the process manager. All the speed of mod_php/perchild hacks and more isolation and portability.
"whatever BSD uses"
pf, ipf, and ipfw, depending on flavour/taste.
Yup. They're using it for cooling.
Opera reports itself as "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.01"; this isn't a case of Opera being completely unidentifiable by default. A swift F12-i and Opera reports "Opera/8.01 (Windows NT 5.1; U; en)"