If you're going to have any swap space at all, you'll need to have at least as much as your current physical RAM - in fact, most people would recommend running with twice that.
The poster didn't say Linux, just a PC. What if he wants to use FreeBSD or Solaris?
Maybe not too much (256 Mb should be fine). But Linux really does not deal well with running out of memory; basically, even if the process that is using the memory dies, your machine is pretty much unusable - reboot is required, if the kernel doesn't do it for you.:)
It's better to have it and never need it than need it and not have it. One server here has 768 megs of PC133 and 2.5 Gigs of swap. Even workstations with 512 Mb of memory get at least 256 megs of it.
Memory is cheap, but so are disks. I would always have some amount of swap around just in case, unless you really really really need the space.
No doubt this was a sw path put in by a well intentioned programmer trying to save battery life, but now all respected encryption systems reccomend a "veil" strategy, where all encryption/decryption operations take the same amount of time and power regardless of the key.
That's not really necessary. All you have to do is randomize the compututation. For example, power analysis of a smart card doing RSA can recover the secret key, if it knew what the input was (in many situtions, a reasonable setting). But if you multiply (or is it exponentiate?) the input by a random number, then do the RSA op, then demask the output, poof! - PA, electromagnetic emission analysis, etc all get very very hard.
Also, it can be hard to disguise your "wasting time" as being part of the computation, if the attacker can, for example, track which memory is being accessed when.
I wonder how well these clockless chips would fare against differential fault analysis; basically progressively destroying gates in the chip and looking at it's output over time. Almost any chip will fail against this attack (but it requires lots of expensive equipment and a fair amount of expertise).
If you write your own strcat, strcmp, strstr etc. in Java and use byte arrays, you'll find that string manipulation is about 70-85% as fast as in plain C - and that's fast enough for just about any purpose you can think of.
If you have to reimplement stuff that even comes with normal C libraries just to get decent speed, I don't quite see the point. If Java's String is slow, you should probably just deal with it.
Of course your productivity advantage is now gone.
Advantage? If people did what you're suggesting, C would probably be a more productive language to program in! I mean, c'mon! You have to re-implement basic functionality to get decent performance?
Yes, Java is not as slow as most people think (for the most part). No, that is not a decent way to get better performance, at least IMHO (I would not consider doing something like what you suggest, nor would, I imagine, most other people, and so if String is slow, then you will see it in your application performance).
Anyway, in the long run Perl has the best string manipulation. So there.:P
Say we're running at 2GHz, which allows a maximum time of 0.5 ns for an instruction.
Not so; many instructions take multiple cycles. Which ones depends on the machine, but multiplication, division, jumps, and of course memory accesses, are usually 2-20 clock cycles to execute.
More time is spend doing memory access and missed branches than anything else (IIRC: Pentium Pro guesses 90% of branches correctly, and missed branches count for about 30% of the overall time of executing a typical piece of code). IA-64 does some interesting things to prevent missed branches from hurting the code (basically, it executes both branches in parallel, throwing away whichever one was wrong). IA-64 has so many functional units that I guess in the long run, it turns out to be a win.
If the advatages they cite for these chips are true, things could get very interesting in a couple of years.:)
Do _all_ US citizens think your laws apply all over the world?...
Nope, just the idiotic politicians.
I'm really wondering the guys pushing this stuff are just really stupid, or if they're taking the opportunity to ban strong crypto while they have a good excuse and everyone is so worked up.
I work at at lab at my university that does just this. It's called CIRL, and sent a team to the recent Robocup competition (we lost).
One of the best parts of using Linux for robot control is you can do some fairly heavy processing on it (for example, put a Firewire DV camera on it, send the output to a firewire card, decode it, run various computer vision algorithms on the input, and decide what to do next).
However, for the lower-level interaction, we mostly use drivers provided by the people who did the robots for us (we're not really a robotics lab, more of a lab that does computer vision, and we test things out on robots). They provide the sources, of course, but it's not free (OTOH, I wouldn't want to have to write the drivers myself, soooo...)
If you are planning on building one yourself (a reasonable idea considering how much the ones we bought cost), I would strongly suggest you consider using some sort of 8 or 16 bit embedded microprocessor or something even smaller, for doing the actual control (another post had some details about this sort of thing). If you're really feeling 31337, wire it all up with just plain transistors (probably make it a real mess and hard to fix if something breaks, though).
Linux is useful enough on a robot, but it's not really a low level controller; you need something to centralize the control of the phyiscal components into one place, so your "real" computer can talk to just that single spot, instaead of some weird scheme where you would have wires running all over the place connecting directly to your computer somehow.
BTW, Wireless LAN cards in robots kick ass.:)
Also, I'm not sure how expensive it is, but look into ARCnet. It's an "embedded networking" sort of thing; some of the robots use it to connect together various parts (radars, cameras, the wheels, etc) and Linux supports it to some extent.
Perl and shell are you friends. Script like it was going out of style. Never do anything manually more than twice (three times tops). This rule will save you a lot of time in the long run.
If you have multiple machines (more my area of experience), NFS, NIS, DNS, LDAP, etc are super-important. Make an NFS'ed/usr/local/etc that contains all the important config files, and a cronjob copies the files over ever N minutes or hours. Redhat and Mandrake have a kickstart system that allows you to re-install a system with minimal effort (probably other Linux distros have something similiar). It's useful. Damn useful.
The high-end hardware is a waste of money with only a 100 users (unless they're constantly hitting the machine hard). One machine we've got here is a 1 Ghz AMD Tbird, Abit KT7A-RAID, 768 Mb PC133, big software striped RAID IDE disks, pretty vanilla (cost us like $1000 in June, it would be $750 today). It handles web (tons of PHP and Perl, also SSL), mail (SMTP, IMAPS, SPOP3), database, rsync, and SSH for 65 people with no problem (plus NIS, NFS'ing out/home, NTP, etc). I'm sure it could take at least 200-300 users before running into any problems (the old server was a 233 Mhz K6 with 128 Megs of memory - it held up suprisingly well for 3 full years with the same load). SCSI, especially, is not worth the money. It's nice, but price/performance on SCSI is not worth it unless you need the fastest possible stuff.
lawn darts they can shake off after a short hospital stay
Maybe if they're lucky, and a large number of sharp, heavy, aerodynamic objects somehow manage to hit them and not kill them. There is a reason they're not sold (at least in the US) anymore... Regular darts would probably just hurt them some, but lawn darts would hurt them a lot.
A horse is a nice idea, but I don't think the roof could take the weight. Maybe I could scoop up some dead rats, however. That would be disgusting in and of itself, of course, but then there's maggots, roaches, whatever, raining down on them. Hmm...
A sufficiently sized and well-trained dog is able come up with it's own food if you live in a neighborhood sporting enough cats.
Very nice.:)
Seriously, however, for cats this is totally true. One of my cats will catch and eat anything from birds, rats/mice/shrews/misc other rodents, various other mammals (I have seen her kill and eat a mole and a very cute little baby jackrabbit - not at the same time, obviously). And also once a big juicy dragonfly, which was kind of gross. Anyway, she rarely eats any cat food at all.
Also, you can feed dogs a reasonable amount of well-chosen scraps, mixed in with dry food, which would pretty easily halve the amount of dog food you buy. My family's dog loves eggs.
robotic dogs are far easier to outfit with light artillery.
True. However, I prefer to reserve such things for mounting on my roof, along with my catapults for launching buckets of urine and lawn darts at stupid kids who stand outside my house at 3 in the morning yelling.
For internal use, I prefer the personal touch. Thus, real dogs, knives, lead pipes, crowbars, etc.
You'll again need to get ahold of the trays if your machine doesn't come with one.
Yeah, that's been my problem. A while back mwave was selling IBM 9 and 18 gig SCA drives for reasonably cheap. But getting ahold of the drive things can be a real PITA. I've got a free slot on my SS5 that I'd like to put a drive into but I can't get ahold of the mounting dealy (which is a rather nice design - I just wish my SS5 had come with 2 of them).
I would consider an Ultra5, but first I want to get ahold of a nice little Alpha. Sun really does make some nice hardware, and I'd like to have a (working) 64-bit machine (I've got an R5000 Indy that's not very cooperative about working). But I've already got a bunch of 32 bit sparcs and I'd like to try out some other systems first.
I've got a 110 Mhz Sparc 5 and various Sparc 2s sitting in my closet. The Sparc 5 is decent, but a bit slow, even running Linux. On a single processor, Solaris is noticably slower than Linux. The finer grained locking lets it scale better but adds lots of useless overhead on a single CPU box. I haven't tried NetBSD or OpenBSD on SPARC yet, but they are probably using coarse-grained locking like Linux, especially OpenBSD, which doesn't support SMP at all and thus has little need for it.
Thus, I would say that you should go for a Sparc 10 or 20, or one of the Ultras if you want to try Solaris (Solaris/x86 can give you the same experience with Solaris on cheaper, faster hardware, though).
One word of warning: Sparc 4/5/10 uses SCA drives, which are weird and can be hard to find, whereas others (SS2, SS20, Ultra*) use SCSI-2, Ultra SCSI, or IDE. Though if somone in the Baltimore area wants to buy some 1 gig SCA drives, let me know.:)
Systems with 64-bit timestamps (like pre-X Mac OS and VMS) won't roll over for the next 20,000 years.
Also, most 64-bit Unix systems are using 64-bit time_t's, since on most systems I've seen, it's a long (I just checked it on Solaris and Linux, but I imagine this is true basically everwhere). So, as long as you're using a 64-bit machine, you're probably safe.
Since by 2038 (rollover time), 32-bit machines will be mostly unused (I imagine that by that time they will only exist as obsolete hardware and embedded stuff), the 32-bit timestamp problem doesn't really exist, at least on the normal programmatic level.
However, many standards (for example OpenPGP), use timestamps which are explicitely 32 bits long. This will cause some problems, but should be fairly simple for implementations to work around (after all, a PGP signature was probably not made in 1970, so you could probably say that if the timestamp comes before some reasonable date, like say 1990 or 1995, just add the appropriate amount of time).
So, for those of you creating formats, remember that 64-bit timestamps are your friend.
The next question: how well does it support firewire?
We're using an external firewire drive here, using the latest stable CVS of the linux firewire drivers. The sbp2 module (which handles firewire drives), seems a little unstable under high load (it locked up twice - HARD - under high loads). By high I mean about 8 gzip processes running at the same time. Other than that the drive seems OK, if a little slow to respond.
YMMV, of course. But unless you've got lots of free time, I might wait a little bit.
c. absolutely no advanced hard drive setup (mirrored drives, striped, etc)
d. absolutely no support for more than a single user
e. absolutely no support for multi-homed networking
f. minimal support for file and resource sharing (printer mount points, etc)
While I agree that you're totally right about all of these points (BeOS's lack of multi-user support has always bothered me), I'm amused to note that a good Unix has them all, but usually much more fully featured (especially a/b/d).
Anyway, considering how often 95/98/etc are used on business desktops, I doubt that was really the issue. Business desktop == Office. End of story. These other things are nice, but meaningless compared to Office. If MS Office doesn't run on it, it will never be a "business desktop", at least not now or in the forseeable future (thought experiment: Imagine how many people would be using Windows 2000 in a business-but-not-server environment if MS Office did not run on it at all. Answer: my guess is about, oh... ~10).
they should be able to classify whatever they want.
Sure they should. That doesn't mean the FBI should be allowed to violate federal wiretapping laws, then claim after the fact that it's classified so they don't get their illegally collected evidence tossed out of court.
Well, I once thought that this http protocol would never catch on (since it was less versitile than ftp)
Um... how, exactly? Keep in mind in your response, I was using archie and gopher before the web was around. I tried out the web a little bit back around that time, and was not particularly impressed (because at the time all the content was on gopher). But anyone could see the system was much more flexible than FTP; it supported, even then, a much more interactive experience than was available on anything else I used at the time, at least.
and all that extra typing of a URL was silly because you really just had to give the hostname of the ftp site and, if it wasn't obvious, the directory to cd to in order to find all your files.
I think we're talking on slightly different scales here. Yeah, an HTTP URL might be more verbose than an FTP URL (though not usually, since FTP sites usually have a deeper directory structure, making them longer to type than HTTP URLs). In any case, it's a factor, of, what 3x expansion? Tops? Versus:
<skeptical>
<amused>
I think this is a load of bull
</amused>
</skeptical>
I will be truly shocked if I ever see even one person use this system in a non-sarcastic manner.
Net-speak changes (and changes very rapidly).
I can't say I agree with you here. Net-speak changes, but not in the sudden, total break manner that this would imply. Reading Usenet and mail archives from 1992, it's still perfectly readable and understandable.
In Ontario (Think Toronto - BlueJays) we get better weather than Buffalo NY !!
Buffalo NY is perhaps not the place to compare Canada to if you're trying to convince USians that Canada isn't cold (my Mom and also my grandfather on my Dad's side are from Canada, BTW). I'm from Oregon, but living in Baltimore; even this place gets really cold (in my book 25F is very cold).
The universal health care system does seem like a good idea, OTOH. I'd rather my tax dollars paid for that than another B-2 bomber or whatever.
VC++ on the Alpha we had to give up on compiling with any optimizations, due to a huge number of bugs. I would not consider the port a big success.
Oh, well. IIRC GCC 2.95.2 (or something thereabouts) had problems on Alpha too. If you compiled with I think -O2 or higher, it would warning you that there were known GCC bugs on that system.
What version were you using? I know they at least managed to build NT, and Win2K RC2, so I can't imagine it would be *that* bad. Or, then again, maybe it was.
Sun's compiler is very bad indeed. The HP one (I'm talking about aCC here, not about their old CC compiler mock up) is OK. It's definitely much better than what Sun tries to push down our throat.
I almost fell out of my chair when I found out that their comiler is like $5000 (I was spec'ing one of these little Sun Blades, and was, like, oh, hey, I might as well pick that up, figuring it would be maybe $100 tops). It cost 2x what the machine would!
I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit.
Yeah, same thing with the Abit KT7A-RAID board. Actually IIRC that's a promise board too, just built into the motherboard.
Those extra ATA/100s are really nice for doing software RAID, though.
I don't know any Welsh, but from what I do know of other languages and the history of the Latin alphabet I would guess that the Y *is* a vowel, and thus that word seems perfectly pronounceable.
Yeah. I don't know Welsh either, but my grandparents do, and it's not half as unpronouncable as it looks. I guess we're getting offtopic here, but whatever.
This is the first time in a while there was an ask slashdot that was both interesting (compare to say the Dorm Storm one a while back), and informative (Alan Cox r00lz, though he may not appreciate me saying it in such a manner).
Are there so few old-time BBSers out that that remember <grin>?:)
I think it's mostly been replaced by <g>
Easier to type, I guess. Or maybe I'm just lazy.
Of course this whole thing is pure silliness. They seem to be expecting that everyone is just going to switch over this weird system over current net-speak. I mean XML is nice and all, but... I kind of doubt a small group of people can come up with a better method of actually communicating emotion/intention than has evolved over the last 15-20 years by literally millions of people. For medical stuff, VR, etc, it could end up having some decent applications, however.
To put it simply, I read the article, and... LOL.:P
Slashdot Mirror
If you're going to have any swap space at all, you'll need to have at least as much as your current physical RAM - in fact, most people would recommend running with twice that.
The poster didn't say Linux, just a PC. What if he wants to use FreeBSD or Solaris?
Maybe not too much (256 Mb should be fine). But Linux really does not deal well with running out of memory; basically, even if the process that is using the memory dies, your machine is pretty much unusable - reboot is required, if the kernel doesn't do it for you. :)
It's better to have it and never need it than need it and not have it. One server here has 768 megs of PC133 and 2.5 Gigs of swap. Even workstations with 512 Mb of memory get at least 256 megs of it.
Memory is cheap, but so are disks. I would always have some amount of swap around just in case, unless you really really really need the space.
No doubt this was a sw path put in by a well intentioned programmer trying to save battery life, but now all respected encryption systems reccomend a "veil" strategy, where all encryption/decryption operations take the same amount of time and power regardless of the key.
That's not really necessary. All you have to do is randomize the compututation. For example, power analysis of a smart card doing RSA can recover the secret key, if it knew what the input was (in many situtions, a reasonable setting). But if you multiply (or is it exponentiate?) the input by a random number, then do the RSA op, then demask the output, poof! - PA, electromagnetic emission analysis, etc all get very very hard.
Also, it can be hard to disguise your "wasting time" as being part of the computation, if the attacker can, for example, track which memory is being accessed when.
I wonder how well these clockless chips would fare against differential fault analysis; basically progressively destroying gates in the chip and looking at it's output over time. Almost any chip will fail against this attack (but it requires lots of expensive equipment and a fair amount of expertise).
If you write your own strcat, strcmp, strstr etc. in Java and use byte arrays, you'll find that string manipulation is about 70-85% as fast as in plain C - and that's fast enough for just about any purpose you can think of.
:P
If you have to reimplement stuff that even comes with normal C libraries just to get decent speed, I don't quite see the point. If Java's String is slow, you should probably just deal with it.
Of course your productivity advantage is now gone.
Advantage? If people did what you're suggesting, C would probably be a more productive language to program in! I mean, c'mon! You have to re-implement basic functionality to get decent performance?
Yes, Java is not as slow as most people think (for the most part). No, that is not a decent way to get better performance, at least IMHO (I would not consider doing something like what you suggest, nor would, I imagine, most other people, and so if String is slow, then you will see it in your application performance).
Anyway, in the long run Perl has the best string manipulation. So there.
Say we're running at 2GHz, which allows a maximum time of 0.5 ns for an instruction.
:)
Not so; many instructions take multiple cycles. Which ones depends on the machine, but multiplication, division, jumps, and of course memory accesses, are usually 2-20 clock cycles to execute.
More time is spend doing memory access and missed branches than anything else (IIRC: Pentium Pro guesses 90% of branches correctly, and missed branches count for about 30% of the overall time of executing a typical piece of code). IA-64 does some interesting things to prevent missed branches from hurting the code (basically, it executes both branches in parallel, throwing away whichever one was wrong). IA-64 has so many functional units that I guess in the long run, it turns out to be a win.
If the advatages they cite for these chips are true, things could get very interesting in a couple of years.
Do _all_ US citizens think your laws apply all over the world? ...
Nope, just the idiotic politicians.
I'm really wondering the guys pushing this stuff are just really stupid, or if they're taking the opportunity to ban strong crypto while they have a good excuse and everyone is so worked up.
Goodbye, US freedom of speech.
I work at at lab at my university that does just this. It's called CIRL, and sent a team to the recent Robocup competition (we lost).
:)
One of the best parts of using Linux for robot control is you can do some fairly heavy processing on it (for example, put a Firewire DV camera on it, send the output to a firewire card, decode it, run various computer vision algorithms on the input, and decide what to do next).
However, for the lower-level interaction, we mostly use drivers provided by the people who did the robots for us (we're not really a robotics lab, more of a lab that does computer vision, and we test things out on robots). They provide the sources, of course, but it's not free (OTOH, I wouldn't want to have to write the drivers myself, soooo...)
If you are planning on building one yourself (a reasonable idea considering how much the ones we bought cost), I would strongly suggest you consider using some sort of 8 or 16 bit embedded microprocessor or something even smaller, for doing the actual control (another post had some details about this sort of thing). If you're really feeling 31337, wire it all up with just plain transistors (probably make it a real mess and hard to fix if something breaks, though).
Linux is useful enough on a robot, but it's not really a low level controller; you need something to centralize the control of the phyiscal components into one place, so your "real" computer can talk to just that single spot, instaead of some weird scheme where you would have wires running all over the place connecting directly to your computer somehow.
BTW, Wireless LAN cards in robots kick ass.
Also, I'm not sure how expensive it is, but look into ARCnet. It's an "embedded networking" sort of thing; some of the robots use it to connect together various parts (radars, cameras, the wheels, etc) and Linux supports it to some extent.
Perl and shell are you friends. Script like it was going out of style. Never do anything manually more than twice (three times tops). This rule will save you a lot of time in the long run.
/usr/local/etc that contains all the important config files, and a cronjob copies the files over ever N minutes or hours. Redhat and Mandrake have a kickstart system that allows you to re-install a system with minimal effort (probably other Linux distros have something similiar). It's useful. Damn useful.
/home, NTP, etc). I'm sure it could take at least 200-300 users before running into any problems (the old server was a 233 Mhz K6 with 128 Megs of memory - it held up suprisingly well for 3 full years with the same load). SCSI, especially, is not worth the money. It's nice, but price/performance on SCSI is not worth it unless you need the fastest possible stuff.
If you have multiple machines (more my area of experience), NFS, NIS, DNS, LDAP, etc are super-important. Make an NFS'ed
The high-end hardware is a waste of money with only a 100 users (unless they're constantly hitting the machine hard). One machine we've got here is a 1 Ghz AMD Tbird, Abit KT7A-RAID, 768 Mb PC133, big software striped RAID IDE disks, pretty vanilla (cost us like $1000 in June, it would be $750 today). It handles web (tons of PHP and Perl, also SSL), mail (SMTP, IMAPS, SPOP3), database, rsync, and SSH for 65 people with no problem (plus NIS, NFS'ing out
lawn darts they can shake off after a short hospital stay
Maybe if they're lucky, and a large number of sharp, heavy, aerodynamic objects somehow manage to hit them and not kill them. There is a reason they're not sold (at least in the US) anymore... Regular darts would probably just hurt them some, but lawn darts would hurt them a lot.
A horse is a nice idea, but I don't think the roof could take the weight. Maybe I could scoop up some dead rats, however. That would be disgusting in and of itself, of course, but then there's maggots, roaches, whatever, raining down on them. Hmm...
A sufficiently sized and well-trained dog is able come up with it's own food if you live in a neighborhood sporting enough cats.
:)
Very nice.
Seriously, however, for cats this is totally true. One of my cats will catch and eat anything from birds, rats/mice/shrews/misc other rodents, various other mammals (I have seen her kill and eat a mole and a very cute little baby jackrabbit - not at the same time, obviously). And also once a big juicy dragonfly, which was kind of gross. Anyway, she rarely eats any cat food at all.
Also, you can feed dogs a reasonable amount of well-chosen scraps, mixed in with dry food, which would pretty easily halve the amount of dog food you buy. My family's dog loves eggs.
robotic dogs are far easier to outfit with light artillery.
True. However, I prefer to reserve such things for mounting on my roof, along with my catapults for launching buckets of urine and lawn darts at stupid kids who stand outside my house at 3 in the morning yelling.
For internal use, I prefer the personal touch. Thus, real dogs, knives, lead pipes, crowbars, etc.
You'll again need to get ahold of the trays if your machine doesn't come with one.
Yeah, that's been my problem. A while back mwave was selling IBM 9 and 18 gig SCA drives for reasonably cheap. But getting ahold of the drive things can be a real PITA. I've got a free slot on my SS5 that I'd like to put a drive into but I can't get ahold of the mounting dealy (which is a rather nice design - I just wish my SS5 had come with 2 of them).
I would consider an Ultra5, but first I want to get ahold of a nice little Alpha. Sun really does make some nice hardware, and I'd like to have a (working) 64-bit machine (I've got an R5000 Indy that's not very cooperative about working). But I've already got a bunch of 32 bit sparcs and I'd like to try out some other systems first.
I think you are wrong about the SCA drive on SS10.
:)
Yeah, I was. Shows how much I know about SPARCS.
I've got a 110 Mhz Sparc 5 and various Sparc 2s sitting in my closet. The Sparc 5 is decent, but a bit slow, even running Linux. On a single processor, Solaris is noticably slower than Linux. The finer grained locking lets it scale better but adds lots of useless overhead on a single CPU box. I haven't tried NetBSD or OpenBSD on SPARC yet, but they are probably using coarse-grained locking like Linux, especially OpenBSD, which doesn't support SMP at all and thus has little need for it.
:)
Thus, I would say that you should go for a Sparc 10 or 20, or one of the Ultras if you want to try Solaris (Solaris/x86 can give you the same experience with Solaris on cheaper, faster hardware, though).
One word of warning: Sparc 4/5/10 uses SCA drives, which are weird and can be hard to find, whereas others (SS2, SS20, Ultra*) use SCSI-2, Ultra SCSI, or IDE. Though if somone in the Baltimore area wants to buy some 1 gig SCA drives, let me know.
Systems with 64-bit timestamps (like pre-X Mac OS and VMS) won't roll over for the next 20,000 years.
Also, most 64-bit Unix systems are using 64-bit time_t's, since on most systems I've seen, it's a long (I just checked it on Solaris and Linux, but I imagine this is true basically everwhere). So, as long as you're using a 64-bit machine, you're probably safe.
Since by 2038 (rollover time), 32-bit machines will be mostly unused (I imagine that by that time they will only exist as obsolete hardware and embedded stuff), the 32-bit timestamp problem doesn't really exist, at least on the normal programmatic level.
However, many standards (for example OpenPGP), use timestamps which are explicitely 32 bits long. This will cause some problems, but should be fairly simple for implementations to work around (after all, a PGP signature was probably not made in 1970, so you could probably say that if the timestamp comes before some reasonable date, like say 1990 or 1995, just add the appropriate amount of time).
So, for those of you creating formats, remember that 64-bit timestamps are your friend.
The next question: how well does it support firewire?
We're using an external firewire drive here, using the latest stable CVS of the linux firewire drivers. The sbp2 module (which handles firewire drives), seems a little unstable under high load (it locked up twice - HARD - under high loads). By high I mean about 8 gzip processes running at the same time. Other than that the drive seems OK, if a little slow to respond.
YMMV, of course. But unless you've got lots of free time, I might wait a little bit.
a. absolutely no remote administration features
b. absolutely no software deployment features
c. absolutely no advanced hard drive setup (mirrored drives, striped, etc)
d. absolutely no support for more than a single user
e. absolutely no support for multi-homed networking
f. minimal support for file and resource sharing (printer mount points, etc)
While I agree that you're totally right about all of these points (BeOS's lack of multi-user support has always bothered me), I'm amused to note that a good Unix has them all, but usually much more fully featured (especially a/b/d).
Anyway, considering how often 95/98/etc are used on business desktops, I doubt that was really the issue. Business desktop == Office. End of story. These other things are nice, but meaningless compared to Office. If MS Office doesn't run on it, it will never be a "business desktop", at least not now or in the forseeable future (thought experiment: Imagine how many people would be using Windows 2000 in a business-but-not-server environment if MS Office did not run on it at all. Answer: my guess is about, oh... ~10).
Sure they should. That doesn't mean the FBI should be allowed to violate federal wiretapping laws, then claim after the fact that it's classified so they don't get their illegally collected evidence tossed out of court.
Well, I once thought that this http protocol would never catch on (since it was less versitile than ftp)
Um... how, exactly? Keep in mind in your response, I was using archie and gopher before the web was around. I tried out the web a little bit back around that time, and was not particularly impressed (because at the time all the content was on gopher). But anyone could see the system was much more flexible than FTP; it supported, even then, a much more interactive experience than was available on anything else I used at the time, at least.
and all that extra typing of a URL was silly because you really just had to give the hostname of the ftp site and, if it wasn't obvious, the directory to cd to in order to find all your files.
I think we're talking on slightly different scales here. Yeah, an HTTP URL might be more verbose than an FTP URL (though not usually, since FTP sites usually have a deeper directory structure, making them longer to type than HTTP URLs). In any case, it's a factor, of, what 3x expansion? Tops? Versus:
<skeptical>
<amused>
I think this is a load of bull
</amused>
</skeptical>
I will be truly shocked if I ever see even one person use this system in a non-sarcastic manner.
Net-speak changes (and changes very rapidly).
I can't say I agree with you here. Net-speak changes, but not in the sudden, total break manner that this would imply. Reading Usenet and mail archives from 1992, it's still perfectly readable and understandable.
In Ontario (Think Toronto - BlueJays) we get better weather than Buffalo NY !!
Buffalo NY is perhaps not the place to compare Canada to if you're trying to convince USians that Canada isn't cold (my Mom and also my grandfather on my Dad's side are from Canada, BTW). I'm from Oregon, but living in Baltimore; even this place gets really cold (in my book 25F is very cold).
The universal health care system does seem like a good idea, OTOH. I'd rather my tax dollars paid for that than another B-2 bomber or whatever.
VC++ on the Alpha we had to give up on compiling with any optimizations, due to a huge number of bugs. I would not consider the port a big success.
Oh, well. IIRC GCC 2.95.2 (or something thereabouts) had problems on Alpha too. If you compiled with I think -O2 or higher, it would warning you that there were known GCC bugs on that system.
What version were you using? I know they at least managed to build NT, and Win2K RC2, so I can't imagine it would be *that* bad. Or, then again, maybe it was.
Sun's compiler is very bad indeed. The HP one (I'm talking about aCC here, not about their old CC compiler mock up) is OK. It's definitely much better than what Sun tries to push down our throat.
I almost fell out of my chair when I found out that their comiler is like $5000 (I was spec'ing one of these little Sun Blades, and was, like, oh, hey, I might as well pick that up, figuring it would be maybe $100 tops). It cost 2x what the machine would!
I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit.
Yeah, same thing with the Abit KT7A-RAID board. Actually IIRC that's a promise board too, just built into the motherboard.
Those extra ATA/100s are really nice for doing software RAID, though.
Yeah. I don't know Welsh either, but my grandparents do, and it's not half as unpronouncable as it looks. I guess we're getting offtopic here, but whatever.
This is the first time in a while there was an ask slashdot that was both interesting (compare to say the Dorm Storm one a while back), and informative (Alan Cox r00lz, though he may not appreciate me saying it in such a manner).
Are there so few old-time BBSers out that that remember <grin>? :)
:P
I think it's mostly been replaced by <g>
Easier to type, I guess. Or maybe I'm just lazy.
Of course this whole thing is pure silliness. They seem to be expecting that everyone is just going to switch over this weird system over current net-speak. I mean XML is nice and all, but... I kind of doubt a small group of people can come up with a better method of actually communicating emotion/intention than has evolved over the last 15-20 years by literally millions of people. For medical stuff, VR, etc, it could end up having some decent applications, however.
To put it simply, I read the article, and... LOL.