UFS is not specifically a Linux filesystem; it was originally developed for one of the BSDs I believe and is used in Free/Open/NetBSD, SunOS, and others.
Now if you could prove that they were using the Linux *implementation* of it, then you'd be on to something...
Not necessarily, though there are limitations. LILO can't boot from a software RAID-5 array, but it can if it's RAID-1.
The way I've got mine set up is with/dev/hd?1 on each drive as a small RAID-1 array where I only put kernel images,/dev/hd?2 as the root filesystem in a RAID-5 set, and/dev/hd?3 as swap.
A program that works in one environment can still suffer from flaws that will prevent it from working in another.
For example, an application might access some memory that is technically out-of-bounds, but the program might still continue working because something else caused that nearby memory to be allocated already and it wasn't being used at the time so there was no corruption. But, the next version of the OS might change the allocation strategy, so now that memory isn't allocated, the program overruns the end of its space, and crashes. Or it's being used for something else that now gets corrupted. The program *is* at fault, but the fault isn't revealed until later on.
The real question though, is did they promise it would work on NT2K in the first place? (I don't remember if they did.) If they never even claimed it would work, then you can't really blame them if it actually doesn't, no matter how much one thinks it *should* work.
I don't really mind having to run it in Classic mode, but what bugs me is that I haven't managed to get it to work with a disk image yet (D2 works fine with one though).
Argh, it's my laptop, I don't want to have to haul CDs around with it...
Shortly before the 1.10 patch came out, GFrazier mentioned on the BNet forums that D2 was actually still a fairly strong seller for Blizzard, and that it still occasionally popped up on the monthly top 10 sales charts. Heck, the battle chest version still sells for $40-$50 CDN in most stores; it's nowhere near the bargain bin.
It may have waned a bit since then now that the patch has been out a while, but it's apparently still popular enough for them to think it's worth supporting.
It's not completely coincidental that 0-100 F happens to correspond to the normal range of temperatures one might experience over the course of a year, with anything below 0 F or above 100 F being clear extremes.
On the other hand, for some of us, -30C to +30C is the nicely symmetric normal temperature range. (In fact it was zero here yesterday. Damn prairies!)
It sort-of works on OS X at the moment (at least for a few trivial programs I've tried), but it has its quirks. Garbage collection doesn't work unless you use an alpha version of the Boehm GC which you'll have to install manually, you need some other libraries like glib that won't be present by default so you have to install them first, the JIT on PPC had a bunch of bugs which have only recently been tackled, and so on.
They're working on it though, and there's been a lot of progress in the last week or two. It's just not quite up to the same level of reliability as the other platforms yet.
To determine if it's worth it, I'd compare it against one of my other hobbies, gaming.
A new game will run me somewhere between $50-$70 CDN, so let's say $60 on average. How much enjoyment am I going to get out of it? Well if it's a half-decent game, I'd want at least 40 hours or so of gameplay, and that would make the effective cost of the game around $1.50 per hour.
To justify paying, say, $1.50 per music track (after currency conversion and rounding for convenience), I'd want at least that same hour of enjoyment out of it. If the song runs 4-5 minutes, I'd have to listen to it 12-15 times before I'd hit that same mark.
So the question is, will I listen to them that often? My favourite tracks, easily; there are a bunch that I'll probably have listened to hundreds of times in my life. Others though, perhaps not. There are some songs I kinda like, but wouldn't deliberately seek out, so the only time I hear them is when they pop up on random shuffle. And other times I'm just playing music in the background and I'm not really paying full attention to it or even caring what it is, so does that really count as fully enjoying it?
In short there are some tracks which I'd say are easily worth the $1 each, but there's plenty of grey area too. At least with the current stores we can pick and choose which ones we think are worth it.
Heh, same here. I rarely do anything more complicated than basic arithmetic anymore, but I'm just too used to my 15C and RPN to use anything else nowadays.
Plus it's amusing to lend it to friends, family, etc. when they ask for a calculator and watch them poke at it for a little while before finally coming back to you saying "Um..." (Unfortunately it doesn't work on coworkers when they're just as geeky as you.)
There is certainly a potential for interference. Electromagnetic compatibility isn't always a straightforward matter; I briefly worked on a software tool to assist in compatibility testing and there are a *huge* number of ways signals from different components in an aircraft can combine and interfere with others. You can't just certify a range of frequencies as being okay and leave it at that, because it also depends on how the frequencies are generated inside the device, which may be different from device to device. Any time a new frequency-generating device was to be added to a plane, it had to undergo fairly extensive testing first.
One case that they were investigating involved a jet that was fitted with extra sensors and transmitters to gather vibration data. After taking off and reaching level flight, the pilot turned on the sensors, only to have the entire avionics system immediately shut down. It took a while before they finally figured out what had happened -- the sensor packages were transmitting on the resonant frequency of a length of metal in the plane, which acted as an antenna and leaked energy into the nearby circuit breaker, which then tripped.
I'm not sure how well this relates to cell phones since these were fairly high-power devices and I'm not familiar with cell phones, but for what it's worth...
Oh! sure, nice, but then the problem is with resources allocated on those 3, 5 or 10 'skipped' levels during exception handling.
Most resources *should* automatically free if they were allocated on the stack, wrapped in an std::auto_ptr, or a guard class whose destructor will do whatever's necessary.
If one of those layers has a resource it knows has the potential to leak anyway, it can add its own exception handler, catch the exception on its way back, release the resource, and then rethrow the exception.
Of course this is still the fundamental problem with languages like C++ -- it works great, *if* you have the discipline to do it properly in the first place...
I was curious and did my own testing a little while ago, comparing a 1GHz iBook G4 against my Athlon 1700XP+ system. The Athlon won all tests in raw speed, but I also normalized against the clock rate to get a work-per-clock-cycle rating.
In general, the G4 was a far bit slower at music encoding to both MP3 and Ogg Vorbis (worse floating point and lack of hand-crafted PPC optimizations?), had a large lead in gzip compression (better cache?), and was roughly equal at encryption.
And of course this was hardly scientific, measured raw CPU speed only, is heavily dependent on compiler optimization (tests were done with GCC 3.2.3 on Linux 2.6.3), cache access patterns, etc., etc., etc...
Looking at the specs, it looks like the following have also changed on the iBook line:
- The default memory doesn't use up the expandable SO-DIMM slot anymore. This previously made upgrading the memory annoying because it was split into 128MB internal and 128MB in the slot, so you were forced to replace memory rather than just add.
- 512KB of L2 cache instead of 256KB.
I got a 1.0GHz iBook a few months ago, but I'm still happy. I wouldn't have waited just for these minor boosts. The SuperDrive may be an option now, but at that price ($280 extra CDN) I'd still rather get an external FireWire drive.
Whenever I think of ID cards, the solution that pops to my mind is to have something with flash-like memory with three blocks of data:
1) A section with my pertinent identification data (picture, description, date of birth, name), in plaintext but cryptographically signed by the government. Anyone that wants to verify my identity can read this area, check the signature, and match the data there against the person standing before them.
2) A for-gov't-eyes-only section, signed and encrypted by the government. This could contain information that should only be revealed to other parts of the government, potentially with different sections and keys for different levels of access, for things like your SIN, passport information, etc. Maybe you're a secret agent and want a way to prove you are, but only to other branches of the government...
The 'spooky' part here would be that if random people can't read the data, then the person holding the card can't read it either so he doesn't even know what's in it other than what the government has told him. I don't think it's really that big a deal though since it's not like they couldn't put anything they want to hide from you in their own hidden databases anyway.
3) And finally, a user block, where a person with an appropriate I/O device can put whatever data they feel is important to keep on them. Medical conditions, organ donation status, favourite type of flowers for the funeral, pictures of your cat, whatever!
Heck, standardize the interface, commoditize it, and let people make their own ID cards and read and write the card themselves. If you don't like that creepy gov't-only block, don't write it to the card. As long as that first, signed block is there, it'll serve its primary purpose.
How about this for a twist: I watch almost no tv, but wish I watched more.
Seriously! I know there is good stuff to be found out there in the nooks and crannies of cable TV, but I just don't have the time to look for it or even watch it anymore. My lack of TV watching is more of a case of negligence than some deliberate 'statement.'
I get all my news on-line, I can watch DVDs on my fairly-large computer screen, and all the quality TV series come out on DVD these days, so for those (very few) shows I can pick them up too. Who needs a TV?
I dunno, maybe it's just habit, but to me there's just something innately more satisfying about slouching back in my nice, comfy living room chair and watching the big tube across the room, even if it is just for stuff on DVD and not actual TV anymore. Trying to watch them on the desktop system or hunched over the laptop are just uncomfortable in comparison.
The reason Apple tried to tie iDVD to their "SuperDrive" systems was more one of ensuring a very cohesive user experience, as opposed to the nightmare of support issues and bad reputation for iDVD as people with 400 MHz G4s tried to use iDVD with any old random DVD recorder.
The story I've heard is that it's actually because of the MPEG-2 licensing. They didn't want to have to pay the license fee for *every* copy of iDVD or iLife sold or given away, so they tied it to the SuperDrive instead. Thus they don't want people using iDVD with a third-party DVD burner since they haven't actually paid the license fee yet.
Of course this is also just hearsay...
It depends on what kind of Mac developer you want to be.
It's easy enough to run the X11 server, install all your familiar old packages via Fink, and use it pretty much like you would have used your previous UNIX setup.
On the other end, if you want to be a 'true' Mac OS X developer, there are a few barriers to overcome:
- Switching from GTK/Qt to the Cocoa or Carbon frameworks
- Learning Objective-C (assuming you use the Cocoa framework)
- Bundling applications and libraries properly
- Following the Aqua UI guidelines
- Integrating with other components like AppleScript nicely
The advantage is that you can at least start out in the old, familiar environment while you work towards learning the new, preferred methods.
(I've recently switched, though I'm still near the 'old-school' end of the spectrum for now.)
It doesn't seem to have hurt Livejournal too much. I would imagine most of the cost is in infrastructure and operations, not code development.
The distributed code doesn't necessarily include *everything*, either. It may be functionally complete, but missing various tweaks and optimizations necessary for really good scalability. Then, as people improve the basic released code, they can fold those improvements back into their own code base and gain those features *and* keep their performance advantage.
I don't really care about the data itself. "Programmer Eats Ramen" isn't exactly going to shock the world if it gets leaked somehow.
If they're going to give me a choice of whether to participate or not though, I'd damn well better be able to choose not to without being hassled about it. Somebody's got to actually exercise that right to remind them that it is a choice.
It's also amusing to see just how far they'll go to try and get me to sign up.
> Besides, how many people keep Windows Media files?
I have to admit I used to, briefly. On devices where you're limited to choosing between WMA and MP3 and with little memory available, WMA sounded better than MP3 did at the really low bitrates. (Disclaimer: To my ears, anyway.)
Other formats can do well at the low end too (insert obligatory Ogg debate here), but the choice might not be available.
One of the design patterns is the 'pimpl', where most of the private members are hidden within a pointer to a separate internal class that is declared but undefined to the external world. You can then make whatever changes you want to the private members in the internal class without changing the header file and triggering those unnecessary rebuilds as long as the public interface hasn't changed. (It also keeps the size of the object constant, for places where that may be important.)
The downside is that now you have to reference all those private members through this extra pointer, which is annoying. That's why it's really only highly recommended for very widely used classes.
The way it's described in the patent, the 'preview' of all of the desktops is hidden until the user specifically triggers it, whereas all the other virtual desktops I'm familiar with have an omnipresent preview on your current desktop.
Of course, this is exactly the kind of trivial difference that disqualifies it from being 'new and non-obvious', so it still deserves to get laughed out of the Patent Office...
They used to. I've got a motherboard with an AMD 761 northbridge, and there was a southbridge available too, though this board didn't use it. I have no idea how its performance compares, but it's been stable as a rock for me.
Slashdot Mirror
UFS is not specifically a Linux filesystem; it was originally developed for one of the BSDs I believe and is used in Free/Open/NetBSD, SunOS, and others.
Now if you could prove that they were using the Linux *implementation* of it, then you'd be on to something...
Not necessarily, though there are limitations. LILO can't boot from a software RAID-5 array, but it can if it's RAID-1.
/dev/hd?1 on each drive as a small RAID-1 array where I only put kernel images, /dev/hd?2 as the root filesystem in a RAID-5 set, and /dev/hd?3 as swap.
The way I've got mine set up is with
A program that works in one environment can still suffer from flaws that will prevent it from working in another.
For example, an application might access some memory that is technically out-of-bounds, but the program might still continue working because something else caused that nearby memory to be allocated already and it wasn't being used at the time so there was no corruption. But, the next version of the OS might change the allocation strategy, so now that memory isn't allocated, the program overruns the end of its space, and crashes. Or it's being used for something else that now gets corrupted. The program *is* at fault, but the fault isn't revealed until later on.
The real question though, is did they promise it would work on NT2K in the first place? (I don't remember if they did.) If they never even claimed it would work, then you can't really blame them if it actually doesn't, no matter how much one thinks it *should* work.
I don't really mind having to run it in Classic mode, but what bugs me is that I haven't managed to get it to work with a disk image yet (D2 works fine with one though).
Argh, it's my laptop, I don't want to have to haul CDs around with it...
Shortly before the 1.10 patch came out, GFrazier mentioned on the BNet forums that D2 was actually still a fairly strong seller for Blizzard, and that it still occasionally popped up on the monthly top 10 sales charts. Heck, the battle chest version still sells for $40-$50 CDN in most stores; it's nowhere near the bargain bin.
It may have waned a bit since then now that the patch has been out a while, but it's apparently still popular enough for them to think it's worth supporting.
It's not completely coincidental that 0-100 F happens to correspond to the normal range of temperatures one might experience over the course of a year, with anything below 0 F or above 100 F being clear extremes.
On the other hand, for some of us, -30C to +30C is the nicely symmetric normal temperature range. (In fact it was zero here yesterday. Damn prairies!)
It sort-of works on OS X at the moment (at least for a few trivial programs I've tried), but it has its quirks. Garbage collection doesn't work unless you use an alpha version of the Boehm GC which you'll have to install manually, you need some other libraries like glib that won't be present by default so you have to install them first, the JIT on PPC had a bunch of bugs which have only recently been tackled, and so on. They're working on it though, and there's been a lot of progress in the last week or two. It's just not quite up to the same level of reliability as the other platforms yet.
To determine if it's worth it, I'd compare it against one of my other hobbies, gaming.
A new game will run me somewhere between $50-$70 CDN, so let's say $60 on average. How much enjoyment am I going to get out of it? Well if it's a half-decent game, I'd want at least 40 hours or so of gameplay, and that would make the effective cost of the game around $1.50 per hour.
To justify paying, say, $1.50 per music track (after currency conversion and rounding for convenience), I'd want at least that same hour of enjoyment out of it. If the song runs 4-5 minutes, I'd have to listen to it 12-15 times before I'd hit that same mark.
So the question is, will I listen to them that often? My favourite tracks, easily; there are a bunch that I'll probably have listened to hundreds of times in my life. Others though, perhaps not. There are some songs I kinda like, but wouldn't deliberately seek out, so the only time I hear them is when they pop up on random shuffle. And other times I'm just playing music in the background and I'm not really paying full attention to it or even caring what it is, so does that really count as fully enjoying it?
In short there are some tracks which I'd say are easily worth the $1 each, but there's plenty of grey area too. At least with the current stores we can pick and choose which ones we think are worth it.
Heh, same here. I rarely do anything more complicated than basic arithmetic anymore, but I'm just too used to my 15C and RPN to use anything else nowadays.
Plus it's amusing to lend it to friends, family, etc. when they ask for a calculator and watch them poke at it for a little while before finally coming back to you saying "Um..." (Unfortunately it doesn't work on coworkers when they're just as geeky as you.)
There is certainly a potential for interference. Electromagnetic compatibility isn't always a straightforward matter; I briefly worked on a software tool to assist in compatibility testing and there are a *huge* number of ways signals from different components in an aircraft can combine and interfere with others. You can't just certify a range of frequencies as being okay and leave it at that, because it also depends on how the frequencies are generated inside the device, which may be different from device to device. Any time a new frequency-generating device was to be added to a plane, it had to undergo fairly extensive testing first.
One case that they were investigating involved a jet that was fitted with extra sensors and transmitters to gather vibration data. After taking off and reaching level flight, the pilot turned on the sensors, only to have the entire avionics system immediately shut down. It took a while before they finally figured out what had happened -- the sensor packages were transmitting on the resonant frequency of a length of metal in the plane, which acted as an antenna and leaked energy into the nearby circuit breaker, which then tripped.
I'm not sure how well this relates to cell phones since these were fairly high-power devices and I'm not familiar with cell phones, but for what it's worth...
Oh! sure, nice, but then the problem is with resources allocated on those 3, 5 or 10 'skipped' levels during exception handling.
Most resources *should* automatically free if they were allocated on the stack, wrapped in an std::auto_ptr, or a guard class whose destructor will do whatever's necessary.
If one of those layers has a resource it knows has the potential to leak anyway, it can add its own exception handler, catch the exception on its way back, release the resource, and then rethrow the exception.
Of course this is still the fundamental problem with languages like C++ -- it works great, *if* you have the discipline to do it properly in the first place...I was curious and did my own testing a little while ago, comparing a 1GHz iBook G4 against my Athlon 1700XP+ system. The Athlon won all tests in raw speed, but I also normalized against the clock rate to get a work-per-clock-cycle rating.
In general, the G4 was a far bit slower at music encoding to both MP3 and Ogg Vorbis (worse floating point and lack of hand-crafted PPC optimizations?), had a large lead in gzip compression (better cache?), and was roughly equal at encryption.
And of course this was hardly scientific, measured raw CPU speed only, is heavily dependent on compiler optimization (tests were done with GCC 3.2.3 on Linux 2.6.3), cache access patterns, etc., etc., etc...
Looking at the specs, it looks like the following have also changed on the iBook line:
- The default memory doesn't use up the expandable SO-DIMM slot anymore. This previously made upgrading the memory annoying because it was split into 128MB internal and 128MB in the slot, so you were forced to replace memory rather than just add.
- 512KB of L2 cache instead of 256KB.
I got a 1.0GHz iBook a few months ago, but I'm still happy. I wouldn't have waited just for these minor boosts. The SuperDrive may be an option now, but at that price ($280 extra CDN) I'd still rather get an external FireWire drive.
Whenever I think of ID cards, the solution that pops to my mind is to have something with flash-like memory with three blocks of data:
1) A section with my pertinent identification data (picture, description, date of birth, name), in plaintext but cryptographically signed by the government. Anyone that wants to verify my identity can read this area, check the signature, and match the data there against the person standing before them.
2) A for-gov't-eyes-only section, signed and encrypted by the government. This could contain information that should only be revealed to other parts of the government, potentially with different sections and keys for different levels of access, for things like your SIN, passport information, etc. Maybe you're a secret agent and want a way to prove you are, but only to other branches of the government...
The 'spooky' part here would be that if random people can't read the data, then the person holding the card can't read it either so he doesn't even know what's in it other than what the government has told him. I don't think it's really that big a deal though since it's not like they couldn't put anything they want to hide from you in their own hidden databases anyway.
3) And finally, a user block, where a person with an appropriate I/O device can put whatever data they feel is important to keep on them. Medical conditions, organ donation status, favourite type of flowers for the funeral, pictures of your cat, whatever!
Heck, standardize the interface, commoditize it, and let people make their own ID cards and read and write the card themselves. If you don't like that creepy gov't-only block, don't write it to the card. As long as that first, signed block is there, it'll serve its primary purpose.
How about this for a twist: I watch almost no tv, but wish I watched more.
Seriously! I know there is good stuff to be found out there in the nooks and crannies of cable TV, but I just don't have the time to look for it or even watch it anymore. My lack of TV watching is more of a case of negligence than some deliberate 'statement.'
I get all my news on-line, I can watch DVDs on my fairly-large computer screen, and all the quality TV series come out on DVD these days, so for those (very few) shows I can pick them up too. Who needs a TV?
I dunno, maybe it's just habit, but to me there's just something innately more satisfying about slouching back in my nice, comfy living room chair and watching the big tube across the room, even if it is just for stuff on DVD and not actual TV anymore. Trying to watch them on the desktop system or hunched over the laptop are just uncomfortable in comparison.
The reason Apple tried to tie iDVD to their "SuperDrive" systems was more one of ensuring a very cohesive user experience, as opposed to the nightmare of support issues and bad reputation for iDVD as people with 400 MHz G4s tried to use iDVD with any old random DVD recorder.
The story I've heard is that it's actually because of the MPEG-2 licensing. They didn't want to have to pay the license fee for *every* copy of iDVD or iLife sold or given away, so they tied it to the SuperDrive instead. Thus they don't want people using iDVD with a third-party DVD burner since they haven't actually paid the license fee yet. Of course this is also just hearsay...It depends on what kind of Mac developer you want to be.
It's easy enough to run the X11 server, install all your familiar old packages via Fink, and use it pretty much like you would have used your previous UNIX setup.
On the other end, if you want to be a 'true' Mac OS X developer, there are a few barriers to overcome:
- Switching from GTK/Qt to the Cocoa or Carbon frameworks
- Learning Objective-C (assuming you use the Cocoa framework)
- Bundling applications and libraries properly
- Following the Aqua UI guidelines
- Integrating with other components like AppleScript nicely
The advantage is that you can at least start out in the old, familiar environment while you work towards learning the new, preferred methods.
(I've recently switched, though I'm still near the 'old-school' end of the spectrum for now.)
It doesn't seem to have hurt Livejournal too much. I would imagine most of the cost is in infrastructure and operations, not code development.
The distributed code doesn't necessarily include *everything*, either. It may be functionally complete, but missing various tweaks and optimizations necessary for really good scalability. Then, as people improve the basic released code, they can fold those improvements back into their own code base and gain those features *and* keep their performance advantage.
I don't really care about the data itself. "Programmer Eats Ramen" isn't exactly going to shock the world if it gets leaked somehow.
If they're going to give me a choice of whether to participate or not though, I'd damn well better be able to choose not to without being hassled about it. Somebody's got to actually exercise that right to remind them that it is a choice.
It's also amusing to see just how far they'll go to try and get me to sign up.
Unfortunately some ISPs are rather fascist about limits. I'd rather not exhaust my entire upload allowance for the month in a single day!
I do try to let it run until I've uploaded at least the same amount as downloaded though.
> Besides, how many people keep Windows Media files?
I have to admit I used to, briefly. On devices where you're limited to choosing between WMA and MP3 and with little memory available, WMA sounded better than MP3 did at the really low bitrates. (Disclaimer: To my ears, anyway.)
Other formats can do well at the low end too (insert obligatory Ogg debate here), but the choice might not be available.
One of the design patterns is the 'pimpl', where most of the private members are hidden within a pointer to a separate internal class that is declared but undefined to the external world. You can then make whatever changes you want to the private members in the internal class without changing the header file and triggering those unnecessary rebuilds as long as the public interface hasn't changed. (It also keeps the size of the object constant, for places where that may be important.)
The downside is that now you have to reference all those private members through this extra pointer, which is annoying. That's why it's really only highly recommended for very widely used classes.
The way it's described in the patent, the 'preview' of all of the desktops is hidden until the user specifically triggers it, whereas all the other virtual desktops I'm familiar with have an omnipresent preview on your current desktop.
Of course, this is exactly the kind of trivial difference that disqualifies it from being 'new and non-obvious', so it still deserves to get laughed out of the Patent Office...
They used to. I've got a motherboard with an AMD 761 northbridge, and there was a southbridge available too, though this board didn't use it. I have no idea how its performance compares, but it's been stable as a rock for me.