A BSD-licenced server implementation that can work on all the major platforms.
Good post, Kjella. #1 is a given. #2, however, is your politics creeping into the game.
I think it's more a valid point than simply politics. Open Standards are much more likely to be adopted if there is a BSD (or similar) licensed implementation.
Do you think TCP/IP would have caught on nearly as well as it did if everybody had to write their own network stack from scratch rather than simply copy the BSD one and modify it slightly? Sure, many (open-and-closed source alike) ended up writing their own eventually, but having the original available for use until then made the protocol able to be adopted much more quickly. Ditto for DNS (BIND), DHCP, SMTP, and other protocols for which a free reference implementation is available.
Some time take a look through the list of RFCs and see how many Internet protocols have been written but either:
Never implemented
Only implemented by the vendor who wrote the protocol (as proprietary software)
Okay, I know that's a Simpsons reference, but I can't quite remember which episode. Is it the one where Bart & Lisa go to military school?
Re:I thought 5.x was the latest
on
FreeBSD 4.9 Released
·
· Score: 3, Informative
although the source is open, the development team is not.
Uh, how exactly is the development team not open? The FreeBSD project accepts contributions from just about anyone -- I've submitted a few patches myself. The list of people with commit rights to the CVS tree is quite large and growing; contrast to the Linux kernel which is a one-man dictatorship (guess how many people have commit rights to the master repo for that).
I started using SFS for my home directory until I realized that it doesn't seem to support file locking at all. D'oh! GNOME and KDE don't appreciate not being able to lock their files.
If by "high performance through client side persistent caching" you mean "has to copy the entire 300MB video from the server to my local machine before it even starts playing, assuming it doesn't crap out because the default cache size is smaller than that", then yeah, go for it!
Seriously, I looked into Coda a couple months ago and the design looks really cool, but it just doesn't seem to work very well unless you're only storing tiny text files. It also doesn't scale very well on large servers (i.e. it has a maximum limit on number the of files on each volume). Don't get me wrong, I REALLY wanted to use Coda because I liked the idea of it -- I just wish that it worked better. Ended up going back to NFS (yuck!).
At least they didn't jump the gun this time
on
FreeBSD 4.9 Released
·
· Score: 4, Funny
Wow, Slashdot posting the story of a BSD release AFTER the official release announcement and the web page being updated? Must be a first.
Re:I thought 5.x was the latest
on
FreeBSD 4.9 Released
·
· Score: 5, Informative
I thought FreeBSD was already on 5.x or something like that. Is that the development version? Does FreeBSD use a linux-like version numbering where odd numbers are development releases?
No, 4.9 is the latest release from the -stable branch. The 5.0 and 5.1 releases were made from the -current development branch (actually the main trunk in CVS). Eventually, probably around 5.2 or 5.3, 5.x will be branched off as 5-STABLE and development will begin on 6.x.
If this product could solve the problem of 2D hardware acceleration, then it might ease the desktop adoption of Linux and *BDS.
I doubt that it would ever be able to work for video drivers, at least not without MASSIVE hacks making it close to useless.
Windows video drivers are designed to run inside the kernel and have direct access to the hardware. XFree86 video drivers (I'm not calling them Linux drivers since XFree86 runs on many other platforms too) run as part of a userspace process and have to use OS-provided facilities like/dev/mem to access the hardware.
Or a memory based file system where there is no distinction between physical memory and hard disk and the OS treats all data access as an access to memory and cachjes out to disk invisibly underneath.
Most modern OS's already do this with the VM/buffer cache.
For me it's more than just to avoid telemarketers. That's just a bonus. You could do it cheaper with a single line and an additional phone number. The first number rings once and the second rings twice.
I'll be all set when they finish installing my PRI with 100 DID numbers at home.:P
It would be nice of someone made a callerid gadget with an ethernet port, so it could do reverse lookups on incoming calls.
I have an old USRobotics voice modem that is great for this. The modem sends the caller ID info over the serial port even if it's not in auto-answer mode.
My home webserver has problems with "referrer spammers" (guys who keeps wasting your bandwidth with false referrer info to get higher scores at Google). Currently I just keep a list of spammers IPs and block them away.
I've seen this before, but never been able to figure out why. Any idea why they think doing this will inprove their Google scores? It's not like Google has access to my web server logs...
The "information superhighway" should be like the physical highway system in the U.S. It should be planned and maintained by the government.
...and we all know how well that works. I can see it now. "As a part of the 'Internet Improvement Project', the root name servers will be unavailable from 9 A.M. to 7 P.M. the week of 11/10 - 11/14."
I don't see any policy that says all trucks bought by a particular government should be Ford, all I see is Government issuing a tender looking for best value in Truck supply.
No, more like a government passing a law that all government-procured vehicles must come with schematics of the engine so that they're not locked in to taking it to the dealer for maintainance. The US military is really anal about this (so stuff can be fixed on-base in the motorpool) which makes it kind of surprising that they use Windows so much.
While I agree that for them to say "All government computers must run Red Hat Linux 7.1" is pretty ridiculous, I could definately see an edict like "All documents published by the government or archived internally must be in an open standard format". So if MS wanted to publish an office suite that could use an open format as its primary format (able to set it as the default for new files and doesn't try to scare the user with messages about "lost formatting" and crap like that) then they would be able to sell to the government.
Oh, and while I'm ranting about the horribleness of Open Source security stuff, why is it that there is STILL no well-integrated filesystem crypto in any of the Open Source operating systems, including the security-oriented OpenBSD? No, loopback crypto kludges don't count at all.
Check out FreeBSD 5's GBDE system. It's still relatively new and needs some polishing, but is improving rapidly. It's already quite usable.
Somehow I don't think this will go over very well with corporate bigwigs. Many PHBs have their secretary print out all of their email and read over it that way... I'd hate to be the IT person responsing to that call.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
Ah, thanks for making my point for me. I can't count the number of times I've seen a Java app crash with a NullPointerException. I'm not talking about Billy's discount water-effects Applet, I mean the big stuff -- ERP systems and other critical things that are supposed to be written very carefully.
Not handling or badly handling exceptions in Java is caused by the same thing that causes buffer overflows in C: laziness. They crash because the programmer didn't think it was possible for something to go wrong there. Garbage in-garbage out applies no matter what language you use.
Take Java. Imagine an application that is set up to handle exceptions at the highest level, but the underpaid contractor who handled the authentication code didn't bother to do any of their own. So an exception gets thrown when verifying the user's password and gets caught by the upper level handler. That handler tries its best to recover from the fault, and ends up happily bypassing the authencation.
Ok, so that example is a bit contrived, but my point is that no language will save you from bad programming and the logic errors that result. What is needed is a mindset that anything can go wrong at any time and you need to be prepared for that.
The right tool for the task applies here too. I agree that for a GUI frontend, something like C++ or wxPython is probably a good idea. But for an OS or a database server or other things that can't afford the bloat, well-commented low-level code that is written defensively can be just as safe.
Without throwing an exception and crashing the program.
No dereferencing of null pointers
Without crashing the program (java.lang.NullPointerException).
No object creation failures (all "new"s succeed)
Without crashing the program -- usually as spectacuarly as a C program since an out-of-memory condition will make Bad Things happen with the VM or JIT as well.
Sounds like a great candidate for writing an OS kernel in. Microsoft are you listening?
You're right - this technology isn't meant for people who don't care about security. It's meant for governments, military, medical and financial service companies, for who keyboard sniffing and tempest monitoring *is* a valid security concern.
And ironically it won't help with either of those. If your keyboard is untrusted (sniffer hooked straight into the circuit) it will still log your keystrokes even if everything on your computer is signed and verified.
Having a secure path between the CPU and the monitor does nothing against tempest. It's the interface between the monitor and the surrounding EM field that tempest snoops on.
Don't forget that LCD monitors are not invulnerable to tempest either.
Slashdot Mirror
Good post, Kjella. #1 is a given. #2, however, is your politics creeping into the game.
I think it's more a valid point than simply politics. Open Standards are much more likely to be adopted if there is a BSD (or similar) licensed implementation.
Do you think TCP/IP would have caught on nearly as well as it did if everybody had to write their own network stack from scratch rather than simply copy the BSD one and modify it slightly? Sure, many (open-and-closed source alike) ended up writing their own eventually, but having the original available for use until then made the protocol able to be adopted much more quickly. Ditto for DNS (BIND), DHCP, SMTP, and other protocols for which a free reference implementation is available.
Some time take a look through the list of RFCs and see how many Internet protocols have been written but either:
Okay, I know that's a Simpsons reference, but I can't quite remember which episode. Is it the one where Bart & Lisa go to military school?
although the source is open, the development team is not.
Uh, how exactly is the development team not open? The FreeBSD project accepts contributions from just about anyone -- I've submitted a few patches myself. The list of people with commit rights to the CVS tree is quite large and growing; contrast to the Linux kernel which is a one-man dictatorship (guess how many people have commit rights to the master repo for that).
I started using SFS for my home directory until I realized that it doesn't seem to support file locking at all. D'oh! GNOME and KDE don't appreciate not being able to lock their files.
If by "high performance through client side persistent caching" you mean "has to copy the entire 300MB video from the server to my local machine before it even starts playing, assuming it doesn't crap out because the default cache size is smaller than that", then yeah, go for it!
Seriously, I looked into Coda a couple months ago and the design looks really cool, but it just doesn't seem to work very well unless you're only storing tiny text files. It also doesn't scale very well on large servers (i.e. it has a maximum limit on number the of files on each volume). Don't get me wrong, I REALLY wanted to use Coda because I liked the idea of it -- I just wish that it worked better. Ended up going back to NFS (yuck!).
Wow, Slashdot posting the story of a BSD release AFTER the official release announcement and the web page being updated? Must be a first.
I thought FreeBSD was already on 5.x or something like that. Is that the development version? Does FreeBSD use a linux-like version numbering where odd numbers are development releases?
No, 4.9 is the latest release from the -stable branch. The 5.0 and 5.1 releases were made from the -current development branch (actually the main trunk in CVS). Eventually, probably around 5.2 or 5.3, 5.x will be branched off as 5-STABLE and development will begin on 6.x.
(2) Computer programs protected by dongles that prevent access due to malfunction or damage and which are obsolete.
They should have extended this to ALL programs protected by dongles -- as long as you have a valid license -- simply on the basis that dongles suck.
If this product could solve the problem of 2D hardware acceleration, then it might ease the desktop adoption of Linux and *BDS.
/dev/mem to access the hardware.
I doubt that it would ever be able to work for video drivers, at least not without MASSIVE hacks making it close to useless.
Windows video drivers are designed to run inside the kernel and have direct access to the hardware. XFree86 video drivers (I'm not calling them Linux drivers since XFree86 runs on many other platforms too) run as part of a userspace process and have to use OS-provided facilities like
Quick! Somebody draft up an RFC for IP-over-Hand-Squeezes.
Or a memory based file system where there is no distinction between physical memory and hard disk and the OS treats all data access as an access to memory and cachjes out to disk invisibly underneath.
Most modern OS's already do this with the VM/buffer cache.
For me it's more than just to avoid telemarketers. That's just a bonus. You could do it cheaper with a single line and an additional phone number. The first number rings once and the second rings twice.
:P
I'll be all set when they finish installing my PRI with 100 DID numbers at home.
Come on man, ironic, you know? It's like rain on your wedding day or a free ride when you've already paid!
But not nearly as ironic as a wedding on your raining day.
It would be nice of someone made a callerid gadget with an ethernet port, so it could do reverse lookups on incoming calls.
I have an old USRobotics voice modem that is great for this. The modem sends the caller ID info over the serial port even if it's not in auto-answer mode.
My home webserver has problems with "referrer spammers" (guys who keeps wasting your bandwidth with false referrer info to get higher scores at Google). Currently I just keep a list of spammers IPs and block them away.
I've seen this before, but never been able to figure out why. Any idea why they think doing this will inprove their Google scores? It's not like Google has access to my web server logs...
Either that or "Various ports closed ahead".
I don't see any policy that says all trucks bought by a particular government should be Ford, all I see is Government issuing a tender looking for best value in Truck supply.
No, more like a government passing a law that all government-procured vehicles must come with schematics of the engine so that they're not locked in to taking it to the dealer for maintainance. The US military is really anal about this (so stuff can be fixed on-base in the motorpool) which makes it kind of surprising that they use Windows so much.
While I agree that for them to say "All government computers must run Red Hat Linux 7.1" is pretty ridiculous, I could definately see an edict like "All documents published by the government or archived internally must be in an open standard format". So if MS wanted to publish an office suite that could use an open format as its primary format (able to set it as the default for new files and doesn't try to scare the user with messages about "lost formatting" and crap like that) then they would be able to sell to the government.
$ sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
www httpd 45226 18 tcp4 127.0.0.1:80 *:*
Check out FreeBSD 5's GBDE system. It's still relatively new and needs some polishing, but is improving rapidly. It's already quite usable.
Somehow I don't think this will go over very well with corporate bigwigs. Many PHBs have their secretary print out all of their email and read over it that way... I'd hate to be the IT person responsing to that call.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
Ah, thanks for making my point for me. I can't count the number of times I've seen a Java app crash with a NullPointerException. I'm not talking about Billy's discount water-effects Applet, I mean the big stuff -- ERP systems and other critical things that are supposed to be written very carefully.
Not handling or badly handling exceptions in Java is caused by the same thing that causes buffer overflows in C: laziness. They crash because the programmer didn't think it was possible for something to go wrong there. Garbage in-garbage out applies no matter what language you use.
Take Java. Imagine an application that is set up to handle exceptions at the highest level, but the underpaid contractor who handled the authentication code didn't bother to do any of their own. So an exception gets thrown when verifying the user's password and gets caught by the upper level handler. That handler tries its best to recover from the fault, and ends up happily bypassing the authencation.
Ok, so that example is a bit contrived, but my point is that no language will save you from bad programming and the logic errors that result. What is needed is a mindset that anything can go wrong at any time and you need to be prepared for that.
The right tool for the task applies here too. I agree that for a GUI frontend, something like C++ or wxPython is probably a good idea. But for an OS or a database server or other things that can't afford the bloat, well-commented low-level code that is written defensively can be just as safe.
No buffer overflows
Without throwing an exception and crashing the program.
No dereferencing of null pointers
Without crashing the program (java.lang.NullPointerException).
No object creation failures (all "new"s succeed)
Without crashing the program -- usually as spectacuarly as a C program since an out-of-memory condition will make Bad Things happen with the VM or JIT as well.
Sounds like a great candidate for writing an OS kernel in. Microsoft are you listening?
Why go to all that trouble?
/usr/src; make kernel KERNCONF=MYFILE
cd
Should CG take off, voice actors will demand pay raises.
Note to self: Develop advanced voice-synthesis technology before Holywood does.
You're right - this technology isn't meant for people who don't care about security. It's meant for governments, military, medical and financial service companies, for who keyboard sniffing and tempest monitoring *is* a valid security concern.
And ironically it won't help with either of those. If your keyboard is untrusted (sniffer hooked straight into the circuit) it will still log your keystrokes even if everything on your computer is signed and verified.
Having a secure path between the CPU and the monitor does nothing against tempest. It's the interface between the monitor and the surrounding EM field that tempest snoops on.
Don't forget that LCD monitors are not invulnerable to tempest either.