Is it just me or would it be a Bad Thing (tm) to let anyone wander around with a BFG in "process killing mode"? One itchy trigger finger and 75 processes bite the dust.
I think Intel should stop this stupidness. What if I want to under-clock my CPU?
(Case in point, I've got PII-266's systems I'd love to plop 333's into, but they don't make those anymore and the current production chips are multiplier locked.)
There are _existing_ (albeit prototypes) 1GHz Alpha CPUs that don't melt lead. My 400MHz EV56 Alpha runs cool enough to hold in my hand despite the elaborate bolt-laged heat sink, and fan channeling (it's a server designed for an equipment farm so it certainly can run perfectly in a 100dF room.)
The Intel PII-333 was a marvel at the time. Even with the fans disconnected, they run cooler than the chipset and RAM:-)
In all fairness, the NT 4.0 install CD is a more than a few years old. I don't expect it to recognize all the wonderful, state-of-the-art goodies in my latest creation. (In fact, it recognizes NONE of them... not even the IDE controller. FWIW, the machine is a Tyan Thunderbolt, dual PIII-450, 1G RAM (4x256 7ns PC-100 SDRAM), 18.3G IBM U2W-LVD, Plextor 40x U2W-SE, 1G JAZ, LS120, Asus V3800D (Ultra TNT2/32M/TV/VR) or Matrox G400 MAX (yes, I switch them.))
I doubt a Redhat 3.0.3 CD would work very well either. (Actually, it'll have the same problem NT does... no support for the SCSI controller.)
I've installed more than your average OSes in my time... various versions of linux (SLS, Slackware, Redhat) for every platform remotely supported, various versions of SCO (Fast Trak?, Unixware, Openserver), various incarnations of Solaris (includes SunOS), versions of Windows predating time, horriblly broken beta's of BeOS, NextStep (once:-)), Digital UNIX (pre-Tru64), a museum of MacOS versions, A/UX, AIX, and <shudder> Ultrix. (TRS-DOS doesn't count:-))
This all comes down to simple common sense. Software can go a long way to protect a system, BUT, if someone has physical access to the machine (i.e. they can touch it, pick it up and put it in their car, etc.) then NOTHING can help you.
Encryption can be broken. I don't know of many people or places that encrypt their harddrive(s). Your data may be secure for some amount of time, but it's now in someone else's hands.
I've resorted to removing a hard drive from a Solaris box once to repair it's root password -- no, it was not compromised; no one knew what the password was and it didn't match any of the known passwords (that we had ever used... for three years.) [And no, there was no other way to do it. Solaris/x86 is a freakin' nightmare if anything ever breaks.]
Umm, I wouldn't call that "software". "Firmware" is a better way to describe it -- very firm-ware, in fact. My '97 Nissan Altima doesn't have a floopy drive for me to change the OS for my iginition system:-)
Most electronic iginition controllers (EEC's) are not easily "field" upgradable. When my Ford Tempo was recalled for emmisions reasons (long time ago), they replaced the fuel injector and the EEC. The work order said "upgrade EEC", but there was a brand new, shiny EEC in there. (I know the Ford EEC4 can be accessed via it's maint. plug. My dad is a mechanic and I've read the (now very dated) specs for the interface -- it's basically a 19.2k serial port. [This should not be read as an excuse to go wire your laptop into your Mustang.])
But, yes, embeded systems programmers are very good bunch of people. They have to be to do what they do with what little they have to work with. Let's see the general/. reader write anything useful in 1K of EEPROM using 128BYTES of RAM.
(I used to do that sort of thing in my youth. I guess that's why I'm such a perfectionist.)
"Embeded programmers do it efficiently." -- T-Shirt
I'd have to ask about the query times for such large data sets. PostgreSQL is not known for blinding speed. (altho' it's gotten better over the years -- removing time travel was a huge improvement.)
None of my databases have ever gotten that huge, but in the fullness of time, they I'm sure they will.
As if every packet you ever send out cannot be traced back to your machine already? Yes, this would make that task so much simpler.
I will point out a massive technical inaccuracy and oversight... the MAC address is not "embedded in your hardware". Sun ethernet cards don't have MAC addresses anywhere on them -- it's generated based on the hostid of the machine (which is very easy to change in the PROM) _AND_ ifconfig supports SETTING the MAC address. It's certainly not etched into the silicon. In most cases, it's trivial to change the address stored in the card's EEPROM.
"Permanently." Are you certain of that? I don't know about every other network card on the planet, but I've never seen one with any carved stone on it.
Gee, maybe EFF and others aren't on the war path because this isn't a problem.
IMO, the author is being a bit of an alarmist here. Why is it people always foam at the mouth about "internet privacy" when they already leave enough of a paper trail for a hamster to track them from another planet? How many credit cards do you have? Do you have a social security number? Do you own a car? (Look at the bottom of your Mountain Dew can some time.)
Actually, there's a mis-print... there shouldn't be a comma (,) after the "I/O". Asynchronous I/O (read: serial ports) existed long before Bill Gates was born. Async I/O completion ports are an NT (or win32s) invention -- if MS is such a wonderous storehouse of innovation, why did they remove this from windows 95 when it was already available to win3.1 via win32s? (I've never understood that.)
Anyway, UNIX (at least linux specifically) you can have a "synchronous write". It's a flag during the open() call to force all buffering to be pass-thru. The write() will not return until the data is commited to the device. There's also the fsync() family of calls to force any queued buffer writes to be commited to disk. (This is much like a database transaction with the notable exception that there is really no way to roll back the write -- heh, unwrite():-))
No, I meant exactly what I said. "JAVA is a complete joke." JAVA is tolerable as a programming language, but any language that allows one to allocate memory but never release it is fundamentally flawed.
In twenty years, no one will be alive with the necessary programming skills to write a real application -- and then who's left to write the VM?
As if C++ didn't add enough convolutions and complications, now we have JAVA. JAVA builds on C++ by removing the need for programmer intelligence.
How many commercial applications are written in PASCAL? (PASCAL is/was designed to teach one how to program; NOT as a language for writing actual programs.)
Go read the "FCode FAQ" at http://solcd.sun.com/ (?) Bascially, the card will not work if there's no resource segment in the openfirmware -- i.e. openboot will not enable the chip or allocate it any PCI resources.
It's easy enough to fix:-) [Recognized and bootable are two vastly different things.]
This from a company that detects the SCSI adapter on x86 by it's BIOS! Yes, the symbios cards have to have a specific BIOS on there or solaris/x86 will not see it. Needless to say I was _very_ ticked off at sun for this blatant idiocy.
I think I'll determine the kind of computer you have by looking at it's power cord.
I work for a company who makes network modeling software (the specifics are not important.) As such, I spend alot of time compiling and testing out what the developers are writing.
When I started here, I inherited a 170MHz Sparc5 with 192M of RAM. It made a fair X-Terminal, but was way way to slow to compile the product and was painfully slow to run the product -- I'd classify the speed as "usable" (barely.) The memory eventually was upped to almost 500M which helped some, but 170MHz turboSparc processor just ain't got the juice to do much.
It was replaced with a 167MHz Ultra 1 with 128M (and a bitchin' high speed Creator 3D gfx card.) I saw very little improvement. I was actually slower at compiling due to the lack of memory. When the memory was upped to 256M, things were better. It's still not the speediest creature in the office (or my apartment for that matter.) BUT, it was a vast improvement over the sparc5.
As I'm one to always ask for (well, alright, demand) faster and faster toys, the ultra 1 was replaced with a 300MHz Ultra10 (192M). While the processor was twice as fast, the lack of memory and the complete thumb-twidling halt every time the IDE disks where accessed just killed that machine. I suppose, given 384M or more of memory would help. However, the slowness of the IDE system prompted a "give me more memory or return the ultra 1."
The Ultra 1 returned with "mem = 458752K (0x1c000000)":-) While the processor is noticablly slower, it's constantly active while building and not hindered by the disk I/O susbsystem(s) (fast-wide SCSI) PLUS, it's got enough memory to avoid agressive swapping.
We ALSO have a fully loaded Ultra60... two 450MHz UltraIIi processors, 2GB of RAM, and two high speed SCSI drives. That machine "just fsckin' screams." (I don't want to see it's price-tag.)
Conclusion... unless you start a compile and leave (or otherwise stop working when you compile), IDE based Ultra's are not the tools one should use for software development. If all you're doing is writing code (or Java) and not building on IDE drive(s), then these things are ok. If you're serious about developing Sparc applications, then spend the money for SCSI based hardware. Oh and tell Sun to burn that worthless PCi card -- it gives you nothing you cannot get in a 300$ PC that doesn't leach resources from the rest of the system.
While I agree with you that it's a serious waste, but they aren't all that bad -- linux runs like a champ.
IDE is bad idea in all cases. But, IDE is "free" with the PCI bridge, so there you have it. In one particular instance, I've seen IDE based Ultra's (5, 10, etc) severely corrupt it's file systems over a few days (mrtg box rapidly creating and deleting files) -- I couldn't reproduce this on a SCSI based system or under linux (which is what that machine continues to run to this day.)
I ESPECIALLY HATE the IDE CD-ROM. Have you tried moving it? Don't. The CD-ROM has to be the master on the secondary bus or the machine locks up. (May just be solaris, but I got tired of the shit and removed all the IDE hardware from the machine -- it happened to have a Swift SCSI controller in it.)
The built-in video is a crappy as all h*** ATI gfx chip (or was a few years ago. _all_ the ultra's around here have Creator gfx cards in them.)
Oh and the thing doesn't use SDRAM. It uses EDO DRAM DIMMs???
All in all, I'd like to have an Ultra. I have no need for that worthless PCi card -- I have more than enough conciderally more power PCs at hand. It would almost certainly run Linux 90% of the time.
It's not "sub" 2k$, it _is_ 2k$. If you want to sell U5's to developers, take that 1k$ PC card out of there and sell them a truely cheap Ultra. The last time I priced an Ultra 5 (a few months ago), a fully loaded SCSI based Ultra5 with 17" monitor was $2500. I don't think this is much of an improvement.
I can get a SCSI based Alpha with Liunx AND Tru64 for 2500$, so what's the point to an IDE based (PoS) Ultra5?
Solaris and Linux are the only OPERATING SYSTEMS that run ON THE ULTRA. Java is not an OS -- it's a joke. Windows and DOS do not run on the Ultra but run on a card (a whole other computer inside a computer) setting on the PCI bus in the Ultra.
This is exactly the same as saying your mac can run Windows and/or DOS.
This is nothing new... Ross (now defunct) used to make a "SparcPlug" that put a hyperSparc inside your PC. There's another company that did the same thing long before Ross but I don't remember the name (and the docs are at home:-)) Of course, the sparcplug was a complete 5.25" FH Sparc computer complete with memory, hard drive, and sbus slot(s). The other one was a PCI card.
(The SparcPlug was a truely innovative marvel. Ross had rack mounting frames for them to load 6 of them per row in a 19" rack. Anyone need a cluster?)
I have an 18G drive with win98 installed well beyond the mythical 1024 mark and it boots perfectly. The true problem is the utter stupidity of LILO (it's always assumed the world is IDE based anyway.)
There's a LILO option to instruct it to use "linear" (-l) address instead of the CHS (3D) address that tops out at 1024. LILO still has trouble with it but it generally works. I cannot get LILO to boot 98 from the "way out" partition, for example.
HOWEVER, getting back to the original thread, there is some major stupidity in the partitioning code in that it will not let you change the types of existing partitions. I'd also like to beat RH over the head for not installing without a swap partition -- I've got 1G of RAM; I'll use a swap FILE just make the kernel happy.
Slashdot Mirror
Umm, the DVD Forum. You know, the people who hold the DVD specs tighter than ... well, you know.
If you don't follow their rules, they revoke your access to the specs and impose a rather serious fine.
Go to the DVD Forum's web site and read this crap for yourself. (http://www.dvdforum.org/)
Is it just me or would it be a Bad Thing (tm) to let anyone wander around with a BFG in "process killing mode"? One itchy trigger finger and 75 processes bite the dust.
"Sorry I kill'd ya', Fidget." - Time Bandits
Yeap, so much for "Plain Old Text", eh?
Use ">" or "<" (WARNING: "Preview" will translate them into the literal chars.)
I think Intel should stop this stupidness. What if I want to under-clock my CPU?
(Case in point, I've got PII-266's systems I'd love to plop 333's into, but they don't make those anymore and the current production chips are multiplier locked.)
Personally, I think it's just marketing FUD.
:-)
There are _existing_ (albeit prototypes) 1GHz Alpha CPUs that don't melt lead. My 400MHz EV56 Alpha runs cool enough to hold in my hand despite the elaborate bolt-laged heat sink, and fan channeling (it's a server designed for an equipment farm so it certainly can run perfectly in a 100dF room.)
The Intel PII-333 was a marvel at the time. Even with the fans disconnected, they run cooler than the chipset and RAM
That's an infinite improbability drive.
The best part is the story behind it's creation... (poor kid)
(If you have to ask, buy the #^%#% book.)
In all fairness, the NT 4.0 install CD is a more than a few years old. I don't expect it to recognize all the wonderful, state-of-the-art goodies in my latest creation. (In fact, it recognizes NONE of them... not even the IDE controller. FWIW, the machine is a Tyan Thunderbolt, dual PIII-450, 1G RAM (4x256 7ns PC-100 SDRAM), 18.3G IBM U2W-LVD, Plextor 40x U2W-SE, 1G JAZ, LS120, Asus V3800D (Ultra TNT2/32M/TV/VR) or Matrox G400 MAX (yes, I switch them.))
:-)), Digital UNIX (pre-Tru64), a museum of MacOS versions, A/UX, AIX, and <shudder> Ultrix. (TRS-DOS doesn't count :-))
I doubt a Redhat 3.0.3 CD would work very well either. (Actually, it'll have the same problem NT does... no support for the SCSI controller.)
I've installed more than your average OSes in my time... various versions of linux (SLS, Slackware, Redhat) for every platform remotely supported, various versions of SCO (Fast Trak?, Unixware, Openserver), various incarnations of Solaris (includes SunOS), versions of Windows predating time, horriblly broken beta's of BeOS, NextStep (once
This all comes down to simple common sense. Software can go a long way to protect a system, BUT, if someone has physical access to the machine (i.e. they can touch it, pick it up and put it in their car, etc.) then NOTHING can help you.
Encryption can be broken. I don't know of many people or places that encrypt their harddrive(s). Your data may be secure for some amount of time, but it's now in someone else's hands.
I've resorted to removing a hard drive from a Solaris box once to repair it's root password -- no, it was not compromised; no one knew what the password was and it didn't match any of the known passwords (that we had ever used... for three years.) [And no, there was no other way to do it. Solaris/x86 is a freakin' nightmare if anything ever breaks.]
Umm, I wouldn't call that "software". "Firmware" is a better way to describe it -- very firm-ware, in fact. My '97 Nissan Altima doesn't have a floopy drive for me to change the OS for my iginition system :-)
/. reader write anything useful in 1K of EEPROM using 128BYTES of RAM.
Most electronic iginition controllers (EEC's) are not easily "field" upgradable. When my Ford Tempo was recalled for emmisions reasons (long time ago), they replaced the fuel injector and the EEC. The work order said "upgrade EEC", but there was a brand new, shiny EEC in there. (I know the Ford EEC4 can be accessed via it's maint. plug. My dad is a mechanic and I've read the (now very dated) specs for the interface -- it's basically a 19.2k serial port. [This should not be read as an excuse to go wire your laptop into your Mustang.])
But, yes, embeded systems programmers are very good bunch of people. They have to be to do what they do with what little they have to work with. Let's see the general
(I used to do that sort of thing in my youth. I guess that's why I'm such a perfectionist.)
"Embeded programmers do it efficiently." -- T-Shirt
Can I get an "Amen, brother!"?
I'd have to ask about the query times for such large data sets. PostgreSQL is not known for blinding speed. (altho' it's gotten better over the years -- removing time travel was a huge improvement.)
None of my databases have ever gotten that huge, but in the fullness of time, they I'm sure they will.
Sure, that works just fine for netscape. (of course, any number of things can futz with your prefs and turn it back on.)
SO, how the fsck does one go about turning off javascript in IE?
Actually, Microsoft has already disproven the million monkeys theory. (either that or they are the exception to prove the rule.)
Umm, that's all fine and dandy, but when did Alan Cox get the kernel version blessing wand (tm)?
"for developers"? Umm, that's what the current 2.3 series is there for. Let's not start down the 2.4pre1 road please.
(btw, as always, apply the mass media filter.)
As if every packet you ever send out cannot be traced back to your machine already? Yes, this would make that task so much simpler.
I will point out a massive technical inaccuracy and oversight... the MAC address is not "embedded in your hardware". Sun ethernet cards don't have MAC addresses anywhere on them -- it's generated based on the hostid of the machine (which is very easy to change in the PROM) _AND_ ifconfig supports SETTING the MAC address. It's certainly not etched into the silicon. In most cases, it's trivial to change the address stored in the card's EEPROM.
"Permanently." Are you certain of that? I don't know about every other network card on the planet, but I've never seen one with any carved stone on it.
Gee, maybe EFF and others aren't on the war path because this isn't a problem.
IMO, the author is being a bit of an alarmist here. Why is it people always foam at the mouth about "internet privacy" when they already leave enough of a paper trail for a hamster to track them from another planet? How many credit cards do you have? Do you have a social security number? Do you own a car? (Look at the bottom of your Mountain Dew can some time.)
Actually, there's a mis-print... there shouldn't be a comma (,) after the "I/O". Asynchronous I/O (read: serial ports) existed long before Bill Gates was born. Async I/O completion ports are an NT (or win32s) invention -- if MS is such a wonderous storehouse of innovation, why did they remove this from windows 95 when it was already available to win3.1 via win32s? (I've never understood that.)
:-))
Anyway, UNIX (at least linux specifically) you can have a "synchronous write". It's a flag during the open() call to force all buffering to be pass-thru. The write() will not return until the data is commited to the device. There's also the fsync() family of calls to force any queued buffer writes to be commited to disk. (This is much like a database transaction with the notable exception that there is really no way to roll back the write -- heh, unwrite()
No, I meant exactly what I said. "JAVA is a complete joke." JAVA is tolerable as a programming language, but any language that allows one to allocate memory but never release it is fundamentally flawed.
In twenty years, no one will be alive with the necessary programming skills to write a real application -- and then who's left to write the VM?
As if C++ didn't add enough convolutions and complications, now we have JAVA. JAVA builds on C++ by removing the need for programmer intelligence.
How many commercial applications are written in PASCAL? (PASCAL is/was designed to teach one how to program; NOT as a language for writing actual programs.)
Go read the "FCode FAQ" at http://solcd.sun.com/ (?) Bascially, the card will not work if there's no resource segment in the openfirmware -- i.e. openboot will not enable the chip or allocate it any PCI resources.
:-) [Recognized and bootable are two vastly different things.]
It's easy enough to fix
This from a company that detects the SCSI adapter on x86 by it's BIOS! Yes, the symbios cards have to have a specific BIOS on there or solaris/x86 will not see it. Needless to say I was _very_ ticked off at sun for this blatant idiocy.
I think I'll determine the kind of computer you have by looking at it's power cord.
*grin* I figured I'd hit my profanity limit :-)
[my sparc machine hopping story...]
:-) While the processor is noticablly slower, it's constantly active while building and not hindered by the disk I/O susbsystem(s) (fast-wide SCSI) PLUS, it's got enough memory to avoid agressive swapping.
I work for a company who makes network modeling software (the specifics are not important.) As such, I spend alot of time compiling and testing out what the developers are writing.
When I started here, I inherited a 170MHz Sparc5 with 192M of RAM. It made a fair X-Terminal, but was way way to slow to compile the product and was painfully slow to run the product -- I'd classify the speed as "usable" (barely.) The memory eventually was upped to almost 500M which helped some, but 170MHz turboSparc processor just ain't got the juice to do much.
It was replaced with a 167MHz Ultra 1 with 128M (and a bitchin' high speed Creator 3D gfx card.) I saw very little improvement. I was actually slower at compiling due to the lack of memory. When the memory was upped to 256M, things were better. It's still not the speediest creature in the office (or my apartment for that matter.) BUT, it was a vast improvement over the sparc5.
As I'm one to always ask for (well, alright, demand) faster and faster toys, the ultra 1 was replaced with a 300MHz Ultra10 (192M). While the processor was twice as fast, the lack of memory and the complete thumb-twidling halt every time the IDE disks where accessed just killed that machine. I suppose, given 384M or more of memory would help. However, the slowness of the IDE system prompted a "give me more memory or return the ultra 1."
The Ultra 1 returned with "mem = 458752K (0x1c000000)"
We ALSO have a fully loaded Ultra60... two 450MHz UltraIIi processors, 2GB of RAM, and two high speed SCSI drives. That machine "just fsckin' screams." (I don't want to see it's price-tag.)
Conclusion... unless you start a compile and leave (or otherwise stop working when you compile), IDE based Ultra's are not the tools one should use for software development. If all you're doing is writing code (or Java) and not building on IDE drive(s), then these things are ok. If you're serious about developing Sparc applications, then spend the money for SCSI based hardware. Oh and tell Sun to burn that worthless PCi card -- it gives you nothing you cannot get in a 300$ PC that doesn't leach resources from the rest of the system.
While I agree with you that it's a serious waste, but they aren't all that bad -- linux runs like a champ.
IDE is bad idea in all cases. But, IDE is "free" with the PCI bridge, so there you have it. In one particular instance, I've seen IDE based Ultra's (5, 10, etc) severely corrupt it's file systems over a few days (mrtg box rapidly creating and deleting files) -- I couldn't reproduce this on a SCSI based system or under linux (which is what that machine continues to run to this day.)
I ESPECIALLY HATE the IDE CD-ROM. Have you tried moving it? Don't. The CD-ROM has to be the master on the secondary bus or the machine locks up. (May just be solaris, but I got tired of the shit and removed all the IDE hardware from the machine -- it happened to have a Swift SCSI controller in it.)
The built-in video is a crappy as all h*** ATI gfx chip (or was a few years ago. _all_ the ultra's around here have Creator gfx cards in them.)
Oh and the thing doesn't use SDRAM. It uses EDO DRAM DIMMs???
All in all, I'd like to have an Ultra. I have no need for that worthless PCi card -- I have more than enough conciderally more power PCs at hand. It would almost certainly run Linux 90% of the time.
It's not "sub" 2k$, it _is_ 2k$. If you want to sell U5's to developers, take that 1k$ PC card out of there and sell them a truely cheap Ultra. The last time I priced an Ultra 5 (a few months ago), a fully loaded SCSI based Ultra5 with 17" monitor was $2500. I don't think this is much of an improvement.
I can get a SCSI based Alpha with Liunx AND Tru64 for 2500$, so what's the point to an IDE based (PoS) Ultra5?
Solaris and Linux are the only OPERATING SYSTEMS that run ON THE ULTRA. Java is not an OS -- it's a joke. Windows and DOS do not run on the Ultra but run on a card (a whole other computer inside a computer) setting on the PCI bus in the Ultra.
:-)) Of course, the sparcplug was a complete 5.25" FH Sparc computer complete with memory, hard drive, and sbus slot(s). The other one was a PCI card.
This is exactly the same as saying your mac can run Windows and/or DOS.
This is nothing new... Ross (now defunct) used to make a "SparcPlug" that put a hyperSparc inside your PC. There's another company that did the same thing long before Ross but I don't remember the name (and the docs are at home
(The SparcPlug was a truely innovative marvel. Ross had rack mounting frames for them to load 6 of them per row in a 19" rack. Anyone need a cluster?)
Not entirely true...
I have an 18G drive with win98 installed well beyond the mythical 1024 mark and it boots perfectly. The true problem is the utter stupidity of LILO (it's always assumed the world is IDE based anyway.)
There's a LILO option to instruct it to use "linear" (-l) address instead of the CHS (3D) address that tops out at 1024. LILO still has trouble with it but it generally works. I cannot get LILO to boot 98 from the "way out" partition, for example.
HOWEVER, getting back to the original thread, there is some major stupidity in the partitioning code in that it will not let you change the types of existing partitions. I'd also like to beat RH over the head for not installing without a swap partition -- I've got 1G of RAM; I'll use a swap FILE just make the kernel happy.