I personally hate gnome-wm (ugly, dysfunctional POS)... btw, what WM is it?
Everyone (including the GDP), and probably most users, have 'standardized' on sawfish. I tried sawmill a few months ago, and there were a few small issues that I didn't like, so I went back to enlightenment, but the newer sawfish releases are really nice (and that's what I'm using now). Probably they'll get rid of gnome-wm completely pretty soon, I doubt there are many people using it.
The first few butterfly pictures are pretty nice - I'd like to see the frame rate on that demo. If its smooth, that's quite impressive - though there are plenty of programming tricks that can be employed to boost performance on the butterflies that aren't immediately obvious - yet would give the impression of serious hardware power.
A couple quotes may shed some light on the subject:
"If it's too good to be true, it's probably a rigged demo"
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
Even if MS suddenly started adding APIs to try and kill WINE, do you really think all the applications for Windows would follow suit?
They can always back-port the stuff - I'm sure that for at least the next few years any DirectX updates will be made for 95, 98, and 2000.
Re:OT: Solaris (wasRe:Wine + Antitrust = Final Nai
on
Wine Works Towards 1.0
·
· Score: 2
To pull this back on topic: how platform-independent is WINE? I'm guessing that it's x86-only (since it's running Windows x86 binaries) but does it work (well) on *BSD, Solaris x86, Be, SCO, etc?
I belive how it works is that it hacks ELF symbols into looking like PE symbols (PE is the format Windows executables use, and they're pretty close - I've heard ELF described as "PE without the cruft") in shared libraries. Of course there's other stuff to emulate having a C: drive, etc, but the main thing in the shared libraries implementing the Windows API and something that will make a Windows executable link with a ELF library. So if it's x86 and ELF, it's probably good to go.
Since I was a bit curious myself, I looked at the Wine FAQ:
UNIXes currently being tested for Wine compatibility include Linux, FreeBSD, and Solaris x86. NetBSD, OpenBSD, Unixware, and SCO OpenServer 5 worked at one time, but Wine now requires kernel-level threads which are not currently available (or understood by the Wine team) in those platforms...
There are side efforts underway to port Wine to the Alpha, OS/2, and BeOS platforms.
Even funkier question (to which I don't expect an answer): can it be compiled on an Alpha-based UNIX system and run Windows NT for Alpha binaries?
That would be pretty interesting (though of course I have to ask just what apps are there for NT on Alpha?!?!?). It would probably be easier to run everything (Wine and the Windows apps) in an x86 emulator, though you'd need a fast machine (which, happily enough, an Alpha is very good at being).
If count is anything over 1, that call to read() is gonna stomp on the stack.
First, PGP isn't SUID, so who cares?
Also, they must be always calling it with an argument of 1, because otherwise PGP5 would SEGV every time you made a key - I doubt there is any way for the user to change that. Though the code does look incredibly sloppy.
If a shared closed-source private algorithm is applied to an otherwise secure piece of cryptotext that was already encrypted via an established open source method, the doubly encrypted message is - at the very least - guaranteed to be no less secure than the singly-encrypted version. If the private algorithm is chosen correctly, the security is most likely enhanced.
Secret algorithms are, in all cases, bad news. Nobody can possibly trust a secret algorithm because nobody can review it. Peer review is as important in crypto as it is in software (if not more, crypto is worth a lot more money). Not to mention the fact that it's hard to write a secret algorithm in OSS.
And don't knock M$ here - have you seen some of the papers they've published?
And they did a such a wonderful job with PPTP, where people found all kinds of nice attacks, including ones which basically ruined the whole point of the protocol (passwords and keys can be recovered, attackers can pretend to be legit servers, etc).
"Anyone attempting to generate random numbers on a digital device is living in a state of sin."?
Found it!
[lloyd@shirley lloyd]$ fortune -m "state of sin" (cookie) % "Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann %
Although, adding some hardware can help solve the entropy problem.
And they're fairly easy to make. A couple guys I know made a RNG that lives on the parallel port and generated random bits by listening to a pair of diodes. They also write a daemon for Linux that reads the data and seeds/dev/random with the bits.
Ideally, a good RNG would be built into every motherboard or CPU. There's enough "really random" stuff going on at the quantum level in there to generate a lot of bits, though collecting most of them would be hard.
Also, I don't hava a VAX handy is there a port of VMS for the i386?
I'm not sure if this is a rhetorical question or not so I'll answer. No, VMS runs on VAX, OpenVMS runs on VAX and Alpha. Basically just like HP-UX or AIX, the point of the OS is mostly to sell hardware (because anything that wants to be popular has to run on Intel).
that one at least some distros (RH comes to mind...),/etc/issue and/etc/issue.net are rebuilt at boot time (on RH in/etc/rc.d/rc.local). So make sure you comment out those lines before making any changes.
Though if you're not running telnet (good move), it doesn't matter much either way (I like have a nice issue message on the console, and ssh doesn't display the issue file).
I wonder if this was ever really a case or if an urban legend made its way into legal circles.
I don't know the answer, but it's best to err on the side of caution. So (if you really have to run telnet - ick), put something like "NO UNAUTHORIZED ACCESS" into your/etc/issue, just to be on the safe side. If this case really happened, you're safe, and if not, well, it doesn't matter either way (I really hope not, though - the idea that people that clueless are running are legal system frightens me).
A system name. 'mail' or 'web' is fine, but everyone loves characters from books, films, etc.
My personal preference is to have two (or more) names for each machine. Like if I had one machine running ftpd, bind, and sendmail, it would be called ftp.randombit.net, dns.randombit.net, and mail.randombit.net, along with a "normal" name like siouxsie or fiona (which the IP address will normally resolve to). That lets you move services from one machine to another with minimal disruption while still getting to use nice names normally.
System status notes. A "We were down last night from 8-12" is a nice notice to have for regular users. Just don't let it get outdated
/etc/motd is generally a better place for that, especially as people ssh'ing will still see it.
They have ported their C, C++, Fortran compilers; math libraries; debuggers; spike optimizing tool and other stuff too...
Comments also seem to indicate that they'd like to, if they could.
I'd like them to do so, too. Not only do they have good Alpha optimizations, but apperantly a lot of stuff that can be applied to any CPU. That would either make nice additions to gcc, or maybe a completely new compiler (based on DECs code, with enhancements taken from gcc, rather than the reverse).
Now that Intel has bought Kuck & Associates (makers of very fast optimizing compliers for C, C++, and Fortran), it would be great to see them open source at least parts of the technology. The standard library they use is proprietary to another company, though I suppose it could be replaced with libstdc++ (for instance, KAI could spend time completing and optimizing that code instead ot the propritetary ones). The basis behind KCC is a bit more anemable to creating front ends for other languages too, I think.
I'm not a crytpo-expert, but my guess is that you would need to use a wide variety of formulaes to even ever discern that there is a pattern, let alone what the patterns signify. But the formulae could be well-tested on a mass-scale via distributed.net and then once a group of likely candidates is discovered, attack them on a massive scale and see if anything hits.
Without knowing exactly what to look for, this probably isn't going to work well. Especially because there almost certainly aren't any patterns in the numbers (this supposition is based entirely off the fact that it's probably the NSA doing it, the NSA does good crypto, and good crypto always looks random). For instance, if I give you some plaintext and cooresponding ciphertext (but not the key), and told you that one of two different ciphers (both good ones) were used to encrypt the data, it's probably not possible to figure out which cipher was used. This probably is much harder: we have to decide among all possible block ciphers - for a n-bit block cipher that's (2**n)!. For 64 or 128 bit block ciphers, that's a big number. Assuming, of course, that they're using a block cipher.:)
Sadly, I suspect that there isn't much hope of cracking these messages... especially if they're using OTP. Without the other side of the message (which probably only the agent had/has), it'll be impossible to decrypt (and I don't mean impossble=="hard", I mean impossible="not possible given infinte computation resources").
Only alphas of 1.6 have been released; things aren't at a beta stage yet.
True, but... (from the webpage) "I'm now planning to release Python 1.6 (final) around June 1st". So either the schedule slipped a bit, or it's a late beta disguised as an alpha.:)
Not necessarily. MPEG-2 compression is almost certainly done in dedicated hardware. Otherwise, you would need the equivalent of a P-II 300 or so just to get it to work, which would make it large, heavy, even more expensive, and pretty hot.
I guess the httpd and Java are done in software, so presumably there's a 32-bit CPU in the somewhere - but how fast it is, I'm not too sure. But there probably isn't much in the way of storage - most of the stuff will be done on flash ROM, I'll bet. Maybe you could hack it to store stuff in the memory for the video, but possibly not (depending on how the hardware interfaces with it).
IIRC, there is an Java API specifically for embedded devices (basically just taking out the less common/useful stuff, I guess). Though I don't know anything about Java so take that with a grain of salt.
I don't know very much about Python (still making my way through Learning Python), but I remember they talk a bit about the cmd module, which is basically a menu-driven interface framework. You supply callbacks, and then run a main loop. (This probably isn't exactly right, see the online Python docs for details).
Hmmm.. Python 1.6 betas are out now, I see. Yummy.:)
What I _wouldn't_ worry about is teaching them a "toy language". Of course they'll learn other languages. Do NOT start them on C or C++. Yes, those are languages "professionals" use.
OK, I agree that 11-13 is a bit too young for starting C or C++. I really can't agree with Java, for the same reasons. At least with C++, you can go from "everything in main()" to "here's what a function looks like" to "this is a class" to "this is the STL". With Java, you have to either explain it all at once, or not explain it at all. I took an intro Java class 1st semester of college (already being a pretty decent C/C++ programmer), and the instructor didn't explain to the class why we had to declare main "public static void" for about 2 months (until that point, it was just "that's the way you have to do it, so do it"). I found it quite frustrating to have to read the book just to get a decent explanation of what's actually going on.
Well, anyway, I vote for Python. Simpler than Perl (IMO), just as complete, and useful in the real world (unlike, say, Logo or Basic).
Wonder why it's taken until now for home designers to start doing that?
I don't know, but I was quite dissapointed when I moved into my new place. It had just been completely renovated, and I figured that since most of the people renting in my area would be college students, wiring a couple lines of CAT5 into each bedroom would be a wise decision. Sadly, they didn't even put in conduit when they installed the phone and cable lines.
That's a serious pain in the ass, since my housemates and I had been planning on sharing a DSL line. I guess I'll have to go buy a drill, now...:/
the OS should be much more of a factor as far as uptimes go... (unless you need/want 1-2 year uptimes). Hardware failures really are few and far between, even for commodity PC hardware - and the Blackfoot seems significantly nicer than that (especially the SCSI drives and controllers). And if it's really a concern you should have redundant, hot-swappable power supplies and hot-swappable SCSI with hardware RAID.
Of course, the question you have to ask yourself is, "Do I really need (or want) this hardware?". If you're planning on running a big site, yes, these look pretty good. However, I spec'ed what might be considered a "reasonably good" server for about $4500. Probably you could get something cheaper by building it yourself (though I _do_ like their Niveus machines)
And just to make this post somewhat offtopic (but related to the use of rack mounted machines), does anyone know where I can get 2U/4U cases and/or small racks online?
Would MKLinux be a decent distro for a web or DNS server, or a possibly a light mail server?
I'm the sysadmin for a student ACM chapter, and we're using mkLinux on a pair of old Macs for our DNS (including a fair number of domains owned by members). They're a bit on the slow side, but, hey, they're old macs. <g>
One of them is also running a web server, with a very old and out of date webpage, here.
Slashdot Mirror
I personally hate gnome-wm (ugly, dysfunctional POS)... btw, what WM is it?
Everyone (including the GDP), and probably most users, have 'standardized' on sawfish. I tried sawmill a few months ago, and there were a few small issues that I didn't like, so I went back to enlightenment, but the newer sawfish releases are really nice (and that's what I'm using now). Probably they'll get rid of gnome-wm completely pretty soon, I doubt there are many people using it.
The first few butterfly pictures are pretty nice - I'd like to see the frame rate on that demo. If its smooth, that's quite impressive - though there are plenty of programming tricks that can be employed to boost performance on the butterflies that aren't immediately obvious - yet would give the impression of serious hardware power.
:)
A couple quotes may shed some light on the subject:
"If it's too good to be true, it's probably a rigged demo"
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
Even if MS suddenly started adding APIs to try and kill WINE, do you really think all the applications for Windows would follow suit?
They can always back-port the stuff - I'm sure that for at least the next few years any DirectX updates will be made for 95, 98, and 2000.
To pull this back on topic: how platform-independent is WINE? I'm guessing that it's x86-only (since it's running Windows x86 binaries) but does it work (well) on *BSD, Solaris x86, Be, SCO, etc?
I belive how it works is that it hacks ELF symbols into looking like PE symbols (PE is the format Windows executables use, and they're pretty close - I've heard ELF described as "PE without the cruft") in shared libraries. Of course there's other stuff to emulate having a C: drive, etc, but the main thing in the shared libraries implementing the Windows API and something that will make a Windows executable link with a ELF library. So if it's x86 and ELF, it's probably good to go.
Since I was a bit curious myself, I looked at the Wine FAQ:
UNIXes currently being tested for Wine compatibility include Linux, FreeBSD, and Solaris x86. NetBSD, OpenBSD, Unixware, and SCO OpenServer 5 worked at one time, but Wine now requires kernel-level threads which are not currently available (or understood by the Wine team) in those platforms...
There are side efforts underway to port Wine to the Alpha, OS/2, and BeOS platforms.
Even funkier question (to which I don't expect an answer): can it be compiled on an Alpha-based UNIX system and run Windows NT for Alpha binaries?
That would be pretty interesting (though of course I have to ask just what apps are there for NT on Alpha?!?!?). It would probably be easier to run everything (Wine and the Windows apps) in an x86 emulator, though you'd need a fast machine (which, happily enough, an Alpha is very good at being).
If count is anything over 1, that call to read() is gonna stomp on the stack.
First, PGP isn't SUID, so who cares?
Also, they must be always calling it with an argument of 1, because otherwise PGP5 would SEGV every time you made a key - I doubt there is any way for the user to change that. Though the code does look incredibly sloppy.
If a shared closed-source private algorithm is applied to an otherwise secure piece of cryptotext that was already encrypted via an established open source method, the doubly encrypted message is - at the very least - guaranteed to be no less secure than the singly-encrypted version. If the private algorithm is chosen correctly, the security is most likely enhanced.
Secret algorithms are, in all cases, bad news. Nobody can possibly trust a secret algorithm because nobody can review it. Peer review is as important in crypto as it is in software (if not more, crypto is worth a lot more money). Not to mention the fact that it's hard to write a secret algorithm in OSS.
And don't knock M$ here - have you seen some of the papers they've published?
And they did a such a wonderful job with PPTP, where people found all kinds of nice attacks, including ones which basically ruined the whole point of the protocol (passwords and keys can be recovered, attackers can pretend to be legit servers, etc).
"Anyone attempting to generate random numbers on a digital device is living in a state of sin."?
Found it!
[lloyd@shirley lloyd]$ fortune -m "state of sin"
(cookie)
%
"Anyone attempting to generate random numbers by deterministic means is, of
course, living in a state of sin."
-- John Von Neumann
%
Although, adding some hardware can help solve the entropy problem.
/dev/random with the bits.
And they're fairly easy to make. A couple guys I know made a RNG that lives on the parallel port and generated random bits by listening to a pair of diodes. They also write a daemon for Linux that reads the data and seeds
Ideally, a good RNG would be built into every motherboard or CPU. There's enough "really random" stuff going on at the quantum level in there to generate a lot of bits, though collecting most of them would be hard.
Also, I don't hava a VAX handy is there a port of VMS for the i386?
I'm not sure if this is a rhetorical question or not so I'll answer. No, VMS runs on VAX, OpenVMS runs on VAX and Alpha. Basically just like HP-UX or AIX, the point of the OS is mostly to sell hardware (because anything that wants to be popular has to run on Intel).
that one at least some distros (RH comes to mind...), /etc/issue and /etc/issue.net are rebuilt at boot time (on RH in /etc/rc.d/rc.local). So make sure you comment out those lines before making any changes.
Though if you're not running telnet (good move), it doesn't matter much either way (I like have a nice issue message on the console, and ssh doesn't display the issue file).
I wonder if this was ever really a case or if an urban legend made its way into legal circles.
/etc/issue, just to be on the safe side. If this case really happened, you're safe, and if not, well, it doesn't matter either way (I really hope not, though - the idea that people that clueless are running are legal system frightens me).
I don't know the answer, but it's best to err on the side of caution. So (if you really have to run telnet - ick), put something like "NO UNAUTHORIZED ACCESS" into your
A system name. 'mail' or 'web' is fine, but everyone loves characters from books, films, etc.
My personal preference is to have two (or more) names for each machine. Like if I had one machine running ftpd, bind, and sendmail, it would be called ftp.randombit.net, dns.randombit.net, and mail.randombit.net, along with a "normal" name like siouxsie or fiona (which the IP address will normally resolve to). That lets you move services from one machine to another with minimal disruption while still getting to use nice names normally.
System status notes. A "We were down last night from 8-12" is a nice notice to have for regular users. Just don't let it get outdated
/etc/motd is generally a better place for that, especially as people ssh'ing will still see it.
They have ported their C, C++, Fortran compilers; math libraries; debuggers; spike optimizing tool and other stuff too...
Comments also seem to indicate that they'd like to, if they could.
I'd like them to do so, too. Not only do they have good Alpha optimizations, but apperantly a lot of stuff that can be applied to any CPU. That would either make nice additions to gcc, or maybe a completely new compiler (based on DECs code, with enhancements taken from gcc, rather than the reverse).
Now that Intel has bought Kuck & Associates (makers of very fast optimizing compliers for C, C++, and Fortran), it would be great to see them open source at least parts of the technology. The standard library they use is proprietary to another company, though I suppose it could be replaced with libstdc++ (for instance, KAI could spend time completing and optimizing that code instead ot the propritetary ones). The basis behind KCC is a bit more anemable to creating front ends for other languages too, I think.
Kinda like making all hammers illegal just because it's possible that some ass may crush your window with one.
Or maybe his stupid head! Where's OOG_THE_CAVEMAN when you need him? OOG could teach this guy some manners with his open source CD!
Having a unique ID in ALL you communication over the internet seems to be what this guy thinks, which is definately NOT a good thing.
:(
For another "real world" equivalent, he wants unique numbers tatooed onto our arms. Oh, wait, that's already been done.
I'm not a crytpo-expert, but my guess is that you would need to use a wide variety of formulaes to even ever discern that there is a pattern, let alone what the patterns signify. But the formulae could be well-tested on a mass-scale via distributed.net and then once a group of likely candidates is discovered, attack them on a massive scale and see if anything hits.
:)
Without knowing exactly what to look for, this probably isn't going to work well. Especially because there almost certainly aren't any patterns in the numbers (this supposition is based entirely off the fact that it's probably the NSA doing it, the NSA does good crypto, and good crypto always looks random). For instance, if I give you some plaintext and cooresponding ciphertext (but not the key), and told you that one of two different ciphers (both good ones) were used to encrypt the data, it's probably not possible to figure out which cipher was used. This probably is much harder: we have to decide among all possible block ciphers - for a n-bit block cipher that's (2**n)!. For 64 or 128 bit block ciphers, that's a big number. Assuming, of course, that they're using a block cipher.
Sadly, I suspect that there isn't much hope of cracking these messages... especially if they're using OTP. Without the other side of the message (which probably only the agent had/has), it'll be impossible to decrypt (and I don't mean impossble=="hard", I mean impossible="not possible given infinte computation resources").
Only alphas of 1.6 have been released; things aren't at a beta stage yet.
:)
True, but... (from the webpage) "I'm now planning to release Python 1.6 (final) around June 1st". So either the schedule slipped a bit, or it's a late beta disguised as an alpha.
Its got to have a pretty fast CPU.
Not necessarily. MPEG-2 compression is almost certainly done in dedicated hardware. Otherwise, you would need the equivalent of a P-II 300 or so just to get it to work, which would make it large, heavy, even more expensive, and pretty hot.
I guess the httpd and Java are done in software, so presumably there's a 32-bit CPU in the somewhere - but how fast it is, I'm not too sure. But there probably isn't much in the way of storage - most of the stuff will be done on flash ROM, I'll bet. Maybe you could hack it to store stuff in the memory for the video, but possibly not (depending on how the hardware interfaces with it).
IIRC, there is an Java API specifically for embedded devices (basically just taking out the less common/useful stuff, I guess). Though I don't know anything about Java so take that with a grain of salt.
I don't know very much about Python (still making my way through Learning Python), but I remember they talk a bit about the cmd module, which is basically a menu-driven interface framework. You supply callbacks, and then run a main loop. (This probably isn't exactly right, see the online Python docs for details).
:)
Hmmm.. Python 1.6 betas are out now, I see. Yummy.
What I _wouldn't_ worry about is teaching them a "toy language". Of course they'll learn other languages. Do NOT start them on C or C++. Yes, those are languages "professionals" use.
OK, I agree that 11-13 is a bit too young for starting C or C++. I really can't agree with Java, for the same reasons. At least with C++, you can go from "everything in main()" to "here's what a function looks like" to "this is a class" to "this is the STL". With Java, you have to either explain it all at once, or not explain it at all. I took an intro Java class 1st semester of college (already being a pretty decent C/C++ programmer), and the instructor didn't explain to the class why we had to declare main "public static void" for about 2 months (until that point, it was just "that's the way you have to do it, so do it"). I found it quite frustrating to have to read the book just to get a decent explanation of what's actually going on.
Well, anyway, I vote for Python. Simpler than Perl (IMO), just as complete, and useful in the real world (unlike, say, Logo or Basic).
although I hear that the high school AP curriculum has switched to C
Actually I believe it was C++. Sadly, they switched a year too late for me, or I would have taken the AP and gotten a few free credits.
Wonder why it's taken until now for home designers to start doing that?
:/
I don't know, but I was quite dissapointed when I moved into my new place. It had just been completely renovated, and I figured that since most of the people renting in my area would be college students, wiring a couple lines of CAT5 into each bedroom would be a wise decision. Sadly, they didn't even put in conduit when they installed the phone and cable lines.
That's a serious pain in the ass, since my housemates and I had been planning on sharing a DSL line. I guess I'll have to go buy a drill, now...
the OS should be much more of a factor as far as uptimes go... (unless you need/want 1-2 year uptimes). Hardware failures really are few and far between, even for commodity PC hardware - and the Blackfoot seems significantly nicer than that (especially the SCSI drives and controllers). And if it's really a concern you should have redundant, hot-swappable power supplies and hot-swappable SCSI with hardware RAID.
Of course, the question you have to ask yourself is, "Do I really need (or want) this hardware?". If you're planning on running a big site, yes, these look pretty good. However, I spec'ed what might be considered a "reasonably good" server for about $4500. Probably you could get something cheaper by building it yourself (though I _do_ like their Niveus machines)
And just to make this post somewhat offtopic (but related to the use of rack mounted machines), does anyone know where I can get 2U/4U cases and/or small racks online?
Would MKLinux be a decent distro for a web or DNS server, or a possibly a light mail server?
I'm the sysadmin for a student ACM chapter, and we're using mkLinux on a pair of old Macs for our DNS (including a fair number of domains owned by members). They're a bit on the slow side, but, hey, they're old macs. <g>
One of them is also running a web server, with a very old and out of date webpage, here.