Yeah, O'caml is great, apart from the awful syntax. Yes, I know about the revised syntax via ocamlp4, but it is not yet standard. And as powerful as the module system is, something like Haskell's typeclasses might be easier to use...
And I really wish more languages would let one define superinterfaces, like Sather.
The biggest fault in it is a hole in the typesystem you can drive a bus through. They try to patch it up with global dataflow analysis, but that hack only half works, and makes seperate compilation a PITA.
(basically, arguments to functions are covariantly typed, when they should be contravariantly typed. This means that
the arguments of a method in a subclass
may be further specialized than the arguments
of the method overridden in the superclass.
This means that at runtime it can throw error.
Instead the arguments a subclass method can take
should only be allowed to be generalized.)
Sather is very similar to Eiffel, and gets this right. But there is only one compiler (though a couple of variants), and it hasn't been updated in a while.
Read the fucking article. It used standard unicast, but in a very clever way. (the part that sends out checks is not the part that listens for responses back.)
Just the opposite actually -- it is usually easier to debug and design. You do have synchronization to avoid reading things at the wrong time, but all the synchronization is local, rather than tied to a global clock pulse, so you only need to verify things at the boundaries, not chipwide at once.
If some unit takes a bit long to respond, you don't get a glitch, as you would in synchronous designs, but instead the unit it is talking too
slows down a bit.
Synchronous and Asynchronous are really misnomers. Better terms would be "globally synchronized" and "locally synchronized".
All of my problems with it have to do with the
onboard sound.
As mentioned, there isn't an internal sound connection, so you can't easily route the cdroms
sound around, short of putting a cable on the front cdrom "headphone" connection and routing it into line-in/microphone on the back.
Also annoying is that you can't mute, or even adjust the volume of the "headphone" out.
Finally, there is some crosstalk between the sound outputs and the video outputs leading to "buzzes" on certain screen backgrounds.
Software-wise: I miss not having a lot of the more versatile gnu utilities pre-installed, but a quick visit to http://www.sunfreeware.com/ fixes that. And, to be fair, they have started shipping a lot more free software.
Well, I'm afraid I have to disagree. If you know C, learning pascal or fortran will not teach you a thing. If you know common lisp, scheme will teach you little. Yes, learning new languages can expand your toolkit greatly, but only if they substantially differ from the ones you already know. I would recommend C, python, some lisp variant, smalltalk or objective C, some ML variant, and prolog or mercury.
Take a look at SFS. It really does look like a secure way to do file sharing. Individual user are authenticated, the host itself is authenticated, and the traffic is encrypted. You do need NFSv3 support, as it is layered on top of it, but it is just about as fast as NFSv3, even with the security. Take a look.
For the latest Linux NFS patches, (to support V3), you'll want to go to nfs.sourceforge.net
Yes, any competent sysadmin would change the password immediately. There are just not enough competent sysadmins though.
You can code software to better deal with common misconfigurations though. In this case the proper thing to do is not perform the normal functions until a password is set. Simple, and it makes it very difficult to have this kind of misconfiguration.
SSH is both a protocol and a decent implementation of that protocol that is easy to deploy.
SRP is a protocol, but implementing it is a pain in the ass. You need special versions of login, telnetd, su, and whatever else does authentication. PAM modules fix some of these problems though.
As far as authentication protocols go, SRP is much nicer than ssh because in addition to authenticating the user to the computer, it authenticates the computer to the user. The SSH implementation does have some resistance to man-in-the-middle attacks, by keeping a cache of known host keys, but this doesn't help much the first time you connect. SRP lets you verify that computer you connect to does indeed have an account with your name and password, it doesn't allow man-in-the-middle attacks.
SRP also has this nice session key lying around afterwards that lets you encrypt, but I know of no programs that actually use it.
Perhaps I am wrong, but as I understood the cookie rfc, a cookie will only be returned to a site if the address is the same as the site that issued it, thus if xyz.com gives you a cookie, a script at doubleclick.com cannot access it
Yes, but they can give out cookies for image requests, and since all of the banner ads come from doubleclick, they can get the cookies.
Slashdot Mirror
Yes, that's what should happen, but UTC is written in to POSIX...
You know what bugs me?
People using idioms incorrectly.
Beyond the _pale_
http://lartc.org/wondershaper/
Dynebolic is an ISO image you can download and boot from, and won't touch your existing install.
One of it's goals is to make it easy to do streaming sound servers.
It's still a bit crude for general music composition use, but kind of nifty.
http://www.dynebolic.org/
Yeah, O'caml is great, apart from the awful syntax. Yes, I know about the revised syntax via ocamlp4, but it is not yet standard. And as powerful as the module system is, something like Haskell's typeclasses might be easier to use...
And I really wish more languages would let one define superinterfaces, like Sather.
(basically, arguments to functions are covariantly typed, when they should be contravariantly typed. This means that the arguments of a method in a subclass may be further specialized than the arguments of the method overridden in the superclass. This means that at runtime it can throw error. Instead the arguments a subclass method can take should only be allowed to be generalized.)
Sather is very similar to Eiffel, and gets this right. But there is only one compiler (though a couple of variants), and it hasn't been updated in a while.
http://www.cs.waikato.ac.nz/sather/
http://www.gnu.org/software/sather/
http://www.icsi.berkeley.edu/~sather/
Read the fucking article. It used standard unicast, but in a very clever way. (the part that sends out checks is not the part that listens for responses back.)
They already do look at (and modify) all port 80 traffic... most ISPs do transparent proxying for web traffic.
Yes, encoding it over valid html/http with the proper caching flags set should actually work fine.
The Reporters Committee for Freedom of the Press provides a reasonable introduction to the laws covering this.
Just the opposite actually -- it is usually easier to debug and design. You do have synchronization to avoid reading things at the wrong time, but all the synchronization is local, rather than tied to a global clock pulse, so you only need to verify things at the boundaries, not chipwide at once.
If some unit takes a bit long to respond, you don't get a glitch, as you would in synchronous designs, but instead the unit it is talking too
slows down a bit.
Synchronous and Asynchronous are really misnomers. Better terms would be "globally synchronized" and "locally synchronized".
All of my problems with it have to do with the
onboard sound.
As mentioned, there isn't an internal sound connection, so you can't easily route the cdroms
sound around, short of putting a cable on the front cdrom "headphone" connection and routing it into line-in/microphone on the back.
Also annoying is that you can't mute, or even adjust the volume of the "headphone" out.
Finally, there is some crosstalk between the sound outputs and the video outputs leading to "buzzes" on certain screen backgrounds.
Software-wise: I miss not having a lot of the more versatile gnu utilities pre-installed, but a quick visit to http://www.sunfreeware.com/ fixes that. And, to be fair, they have started shipping a lot more free software.
Every time I hear about the GAO, it is in such a way that it is demonstrating the incompetence of other agencies. They deserve many pats on the back.
Well, I'm afraid I have to disagree. If you know C, learning pascal or fortran will not teach you a thing. If you know common lisp, scheme will teach you little. Yes, learning new languages can expand your toolkit greatly, but only if they substantially differ from the ones you already know. I would recommend C, python, some lisp variant, smalltalk or objective C, some ML variant, and prolog or mercury.
For the latest Linux NFS patches, (to support V3), you'll want to go to nfs.sourceforge.net
You can code software to better deal with common misconfigurations though. In this case the proper thing to do is not perform the normal functions until a password is set. Simple, and it makes it very difficult to have this kind of misconfiguration.
How about non-realtime though? Isn't it getting computationally feasible to make a video showing someone commiting crimes they didn't do?
If the case is titanium, shouldn't they use that new Itanium chip?
*sigh*. Hopefully meta-moderation will catch it.
See this link on the NetBSD website.
I actually rode on the simulator that used the picture here It was a fun ride.
SRP is a protocol, but implementing it is a pain in the ass. You need special versions of login, telnetd, su, and whatever else does authentication. PAM modules fix some of these problems though.
As far as authentication protocols go, SRP is much nicer than ssh because in addition to authenticating the user to the computer, it authenticates the computer to the user. The SSH implementation does have some resistance to man-in-the-middle attacks, by keeping a cache of known host keys, but this doesn't help much the first time you connect. SRP lets you verify that computer you connect to does indeed have an account with your name and password, it doesn't allow man-in-the-middle attacks.
SRP also has this nice session key lying around afterwards that lets you encrypt, but I know of no programs that actually use it.
32 voted against, 20 for. Apparently 40% are just that bad.