How true. Consider that the male image on Voyager had a teeny tiny penis, and it all starts to make sense.
The other option is a return message on a plaque, depicting a male alien with really large reproductive organs. That'll tell us, more than almost anything else, what sort of mentality we're dealing with.
Yes, in theory. In theory, other cryptosystems are easy well understood, standard, and easy to put in security products, which is true to an extent, but there's still a lot implementors can do to misuse a cryptographically secure RNG. A famous example is how the Russians used some of their one time pads multiple times, making it possible for the Americans to crack their encryption.
Implementing OTP isn't harder than implementing any other cryptosystem, but it isn't easier, either, and relying on hardware solutions introduces yet another thing that could break (What happens if your lava lamp burns and the lava stops bubbling? Is your system still as secure? Chances are that you don't really know. I certainly don't.)
It's a time shifting problem. It works when you have a secure channel right now, but you won't have it later. You transmit the key over the temporary secure channel (i.e. Alice hands the OTP to Bob over lunch) and then transmit the secured message when the secure channel isn't available (Bob encrypts and emails a message to Alice a week later).
You're right that it doesn't have as many useful applications as other cryptosystems in use today.
It's also very hard to produce good (secure) one time pads.
In most cases, you can. Emails asking you to validate something about an account are always fraud. Bad spelling is strongly correlated with fraud, in my experience. PayPal emails never have links that conveniently get you to a log in page - they always give you step by step instructions on how to do what they're asking you to do. And most importantly, if an email threatens you to suspend your account if you don't do what it tells you to, it's fraud.
Believe me, if I wanted to deride this gentleman, I could have - the comments on his web page are just asking for it. I'm willing to give him the benefit of the doubt, even though everything about this project gives me reason to believe it's going nowhere, but I don't know the guy, he might grow up, listen to good advice, or just manage to transform himself into a hyperproductive developer capable of delivering top-notch software products in no time flat, and actually produce something of value, based on his vision of a slimmer, better, GNOME.
Do I think it's likely? Nope. Do I think it's impossible? Of course not, but you won't see me holding my breath, either.
I just finished reading the rant/mission statement on the project's home page. This looks like some guy is unhappy because GNOME doesn't quite fit his vision of what a Real Man's Unix Desktop should be, and he's ready to mobilize the entire FOSS community to 'fix' things. He seems to take some of the UI choices in GNOME really personally, too.
I'm willing to give this effort a year just to see whether the rhetoric is backed by any ability.
Ok, I guess I was trying to say you don't have to read bestsellers, or watch American Idol, or listen to whatever it is that tops the charts right now. Go to a library for books, and go get this album:
Re:I'm with Tannebaum about microkernels
on
More From Tanenbaum
·
· Score: 1
Bad example. It's like running Windows 3.1 and wanting DirectX to run some games. You have to upgrade - there's no way you can just drop DirectX on that old kernel.
You had the same situation with Linux - you had a kernel that didn't support certain features, and you had to upgrade, rather than modprove a driver. This should be a relatively rare situation.
And I have to disagree with you - recompiling kernels stopped being fun for me in 1993. Maybe because I was compiling them on a 386. What I end up doing today is wait for the distribution maintainers to fix things, and then do a yum update, or something like that. Takes about 10 minutes, and less messing than with Windows. When fixes are available and do what I want, that is...
Re:I'm with Tannebaum about microkernels
on
More From Tanenbaum
·
· Score: 1
Everything you mentioned has to do with system interfaces, not with microkernel vs. monolithic design. NT's interfaces tend to remain stable, while Linux's evolve.
Microkernel based operating systems can also evolve their interfaces. Try mixing QNX servers from different releases and see how far you get. I saw QNX drivers that required specific OS versions - 4.23 vs. 4.25, for example. QNX4 had a Linux like tendency to evolve its internal interfaces, and in my experience, at least QNX4 was less stable than the then current Linux version.
I was pointing out that the grandfather post made a statement about the merits of microkernels, and then went off on to rant about things that either had nothing to do with microkernels, or are just plain wrong, in an apparent attempt to prove said statement.
Re:I'm with Tannebaum about microkernels
on
More From Tanenbaum
·
· Score: 3, Informative
What are you talking about? Windows isn't a microkernel, loadable modules have nothing to do with microkernels, almost all device drivers in a modern Linux distributions are loadable modules, and while Tannenbaum may be right, it's not for any of the reasons you mention.
Yes, but not because of the small speedup. (Going from 2 seconds to 1.5 seconds won't be very obvious - if it isn't twice as fast, the difference is lost on most users.)
The refactoring you're proposing, however, makes it easier to change the code later, since you don't have to worry about modifying the view widget and breaking the calculation. The results are computed in one place, making maintenance easier. It's the right thing to do, and being faster is just a bonus.
I think it's worth noting that this guy's optimized version, while fast enough for his purposes, is probably a couple of orders of magnitudes slower than it can be: The 333 MHz Pentium II he squeezes 5 frames and some change out of can decode 30 frames/sec of MPEG-2 video and stereo AC-3 audio without breaking a sweat. The machine I use to watch DVDs is a 300MHz Pentium II. Decoding an MPEG-2 frame involves a bit more computation than decoding an RLE encoded image. Just reading and decoding the DCT coefficients for an MPEG-2 I Frame would take more computation than decoding an entire targa file.
So, yes, interpreted languages are great, and fast enough for most applications, but they're not suitable for everything, as the author ironically illustrates.
What the hell are you talking about? KDE and GNOME have both been translated to Arabic, and I believe Mozilla as well.
The last I tried (a couple of days ago), Mozilla Mail still had some problems with bidirectional text editing. I'd call it marginally useable at this point - the functionality is there, and works, but there's no acceptable UI to allow new users to access it, and there are some annoyances, like plaintext messages displayed with the wrong directionality. Check out bug 96057 in the Mozilla Bugzilla.
KMail appears to work fine, until you try to read BiDi messages it formats with other mailers. They don't display correctly.
Evolution doesn't seem to support BiDi editing at all.
If there is good support for bidirectional e-mail somewhere, I'd love to hear about it, but I wasn't able to find anything I could give my parents and not hear complaints about me breaking their computer...
Parent has a valid point. Why should Linux apps slavishly imitate other UIs?
As someone who slavishly imitated another UI (a management app that ships with a piece of hardware, and was Windows only), I feel qualified to answer that.
While I was planning to eventually write end user documentation for the program, I didn't plan on heaving it ready early on in the release cycle. Basing my program's UI on the screenshots in the Windows product's documentation assured me that the UI will be documented somewhere, possibly making the code easier to use for some people.
So, to answer your question - users like a familiar UI, and Open Source programmers want their programs to be liked.
Hardware manufacturers will probably see better results if they take a more active role in developing Linux drivers than if they just released Windows source and hoped that the Linux developer community will pick it up. As someone who wrote drivers based on Windows code as hardware "specs", I can attest that this isn't fun.
The hardware manufacturer is betting that there are enough people out there with access to the hardware in question and the skills to write a solid driver, and that they'll do it for free. This isn't always the case. They might have more success if they offered free hardware to qualifying developers, or if they simply paid someone to develop a open source driver. There's a better chance that they'd find volunteers to maintain a driver than to write one from scratch, especially since networking devices are pretty cheap and it's easier and cheaper to get another NIC than it is to write a driver for an unsupported one.
By the way, I followed the obvious trail from your homepage to your resume, and from there to SourceForge, and couldn't find a project that fits your description. I'm not saying that it doesn't exist, just that it wasn't obvious to me where to find the released package you mentioned. I wanted to find out whether the networking chip you mentioned is widely used, or so rare that trying to find a random Linux user that has a device using that chip is a hopeless bet.
So tell the compiler to output assembly code instead of object code.
I'd also have to tell it to generate code that conforms to the Linux C++ ABI. The problem is, Microsoft's compiler doesn't know how to do that, or how to call Linux syscalls, or how to mangle names so you'd be able to call native C++ libraries, or how to throw exceptions correctly, and I'm probably missing something.
Sure, you'd be able to futz with the uncommented assembly code by hand to make it work, but doing it automatically as part of a predictable build process is a very hard problem.
It might be possible to run in under Wine to cross compile Windows applications. I'd expect it to be very hard to impossible to convert VC++ created object files to anything that would can be linked to create a Linux app.
Then we just need a version of Autoconf that builds a makefile for the compiler of your choice (gcc, icc, or mscc).
The last thing we need is another version of autoconf.
I should mention that Dev-C++ uses the GNU toolchain as its back end, and won't work with the Borland compiler. You should probably consider using a more standards compliant compiler for school work, anyway.
Slashdot Mirror
And more disturbing (to me at least) is the fact that from the top 10 gaining queries I recognized only one name. Who are all these people?
No, that would in one o' dose TOP
SECRET LABMO-TORIES de gubbnint keep stashed away underneath Virginia.
How true. Consider that the male image on Voyager had a teeny tiny penis, and it all starts to make sense.
The other option is a return message on a plaque, depicting a male alien with really large reproductive organs. That'll tell us, more than almost anything else, what sort of mentality we're dealing with.
Yes, in theory. In theory, other cryptosystems are easy well understood, standard, and easy to put in security products, which is true to an extent, but there's still a lot implementors can do to misuse a cryptographically secure RNG. A famous example is how the Russians used some of their one time pads multiple times, making it possible for the Americans to crack their encryption.
Implementing OTP isn't harder than implementing any other cryptosystem, but it isn't easier, either, and relying on hardware solutions introduces yet another thing that could break (What happens if your lava lamp burns and the lava stops bubbling? Is your system still as secure? Chances are that you don't really know. I certainly don't.)
It's a time shifting problem. It works when you have a secure channel right now, but you won't have it later. You transmit the key over the temporary secure channel (i.e. Alice hands the OTP to Bob over lunch) and then transmit the secured message when the secure channel isn't available (Bob encrypts and emails a message to Alice a week later).
You're right that it doesn't have as many useful applications as other cryptosystems in use today.
It's also very hard to produce good (secure) one time pads.
I used to read his stuff 10 years ago. He didn't have a clue even then.
The Ctrl key is in the placd God intended.
Bah. Shows what she knows - if she had her way, we won't be able to do a - with one hand.
In most cases, you can. Emails asking you to validate something about an account are always fraud. Bad spelling is strongly correlated with fraud, in my experience. PayPal emails never have links that conveniently get you to a log in page - they always give you step by step instructions on how to do what they're asking you to do. And most importantly, if an email threatens you to suspend your account if you don't do what it tells you to, it's fraud.
Believe me, if I wanted to deride this gentleman, I could have - the comments on his web page are just asking for it. I'm willing to give him the benefit of the doubt, even though everything about this project gives me reason to believe it's going nowhere, but I don't know the guy, he might grow up, listen to good advice, or just manage to transform himself into a hyperproductive developer capable of delivering top-notch software products in no time flat, and actually produce something of value, based on his vision of a slimmer, better, GNOME.
Do I think it's likely? Nope. Do I think it's impossible? Of course not, but you won't see me holding my breath, either.
I just finished reading the rant/mission statement on the project's home page. This looks like some guy is unhappy because GNOME doesn't quite fit his vision of what a Real Man's Unix Desktop should be, and he's ready to mobilize the entire FOSS community to 'fix' things. He seems to take some of the UI choices in GNOME really personally, too.
I'm willing to give this effort a year just to see whether the rhetoric is backed by any ability.
Ok, I guess I was trying to say you don't have to read bestsellers, or watch American Idol, or listen to whatever it is that tops the charts right now. Go to a library for books, and go get this album:
ttp://www.cdbaby.com/cd/bryanbeller
There's more to reading than sci-fi, you know.
Bad example. It's like running Windows 3.1 and wanting DirectX to run some games. You have to upgrade - there's no way you can just drop DirectX on that old kernel.
You had the same situation with Linux - you had a kernel that didn't support certain features, and you had to upgrade, rather than modprove a driver. This should be a relatively rare situation.
And I have to disagree with you - recompiling kernels stopped being fun for me in 1993. Maybe because I was compiling them on a 386. What I end up doing today is wait for the distribution maintainers to fix things, and then do a yum update, or something like that. Takes about 10 minutes, and less messing than with Windows. When fixes are available and do what I want, that is...
Everything you mentioned has to do with system interfaces, not with microkernel vs. monolithic design. NT's interfaces tend to remain stable, while Linux's evolve.
Microkernel based operating systems can also evolve their interfaces. Try mixing QNX servers from different releases and see how far you get. I saw QNX drivers that required specific OS versions - 4.23 vs. 4.25, for example. QNX4 had a Linux like tendency to evolve its internal interfaces, and in my experience, at least QNX4 was less stable than the then current Linux version.
I was pointing out that the grandfather post made a statement about the merits of microkernels, and then went off on to rant about things that either had nothing to do with microkernels, or are just plain wrong, in an apparent attempt to prove said statement.
What are you talking about? Windows isn't a microkernel, loadable modules have nothing to do with microkernels, almost all device drivers in a modern Linux distributions are loadable modules, and while Tannenbaum may be right, it's not for any of the reasons you mention.
Yes, but not because of the small speedup. (Going from 2 seconds to 1.5 seconds won't be very obvious - if it isn't twice as fast, the difference is lost on most users.)
The refactoring you're proposing, however, makes it easier to change the code later, since you don't have to worry about modifying the view widget and breaking the calculation. The results are computed in one place, making maintenance easier. It's the right thing to do, and being faster is just a bonus.
I think it's worth noting that this guy's optimized version, while fast enough for his purposes, is probably a couple of orders of magnitudes slower than it can be: The 333 MHz Pentium II he squeezes 5 frames and some change out of can decode 30 frames/sec of MPEG-2 video and stereo AC-3 audio without breaking a sweat. The machine I use to watch DVDs is a 300MHz Pentium II. Decoding an MPEG-2 frame involves a bit more computation than decoding an RLE encoded image. Just reading and decoding the DCT coefficients for an MPEG-2 I Frame would take more computation than decoding an entire targa file.
So, yes, interpreted languages are great, and fast enough for most applications, but they're not suitable for everything, as the author ironically illustrates.
What the hell are you talking about? KDE and GNOME have both been translated to Arabic, and I believe Mozilla as well.
The last I tried (a couple of days ago), Mozilla Mail still had some problems with bidirectional text editing. I'd call it marginally useable at this point - the functionality is there, and works, but there's no acceptable UI to allow new users to access it, and there are some annoyances, like plaintext messages displayed with the wrong directionality. Check out bug 96057 in the Mozilla Bugzilla.
KMail appears to work fine, until you try to read BiDi messages it formats with other mailers. They don't display correctly.
Evolution doesn't seem to support BiDi editing at all.
If there is good support for bidirectional e-mail somewhere, I'd love to hear about it, but I wasn't able to find anything I could give my parents and not hear complaints about me breaking their computer...
Parent has a valid point. Why should Linux apps slavishly imitate other UIs?
As someone who slavishly imitated another UI (a management app that ships with a piece of hardware, and was Windows only), I feel qualified to answer that.
While I was planning to eventually write end user documentation for the program, I didn't plan on heaving it ready early on in the release cycle. Basing my program's UI on the screenshots in the Windows product's documentation assured me that the UI will be documented somewhere, possibly making the code easier to use for some people.
So, to answer your question - users like a familiar UI, and Open Source programmers want their programs to be liked.
Hardware manufacturers will probably see better results if they take a more active role in developing Linux drivers than if they just released Windows source and hoped that the Linux developer community will pick it up. As someone who wrote drivers based on Windows code as hardware "specs", I can attest that this isn't fun.
The hardware manufacturer is betting that there are enough people out there with access to the hardware in question and the skills to write a solid driver, and that they'll do it for free. This isn't always the case. They might have more success if they offered free hardware to qualifying developers, or if they simply paid someone to develop a open source driver. There's a better chance that they'd find volunteers to maintain a driver than to write one from scratch, especially since networking devices are pretty cheap and it's easier and cheaper to get another NIC than it is to write a driver for an unsupported one.
By the way, I followed the obvious trail from your homepage to your resume, and from there to SourceForge, and couldn't find a project that fits your description. I'm not saying that it doesn't exist, just that it wasn't obvious to me where to find the released package you mentioned. I wanted to find out whether the networking chip you mentioned is widely used, or so rare that trying to find a random Linux user that has a device using that chip is a hopeless bet.
So tell the compiler to output assembly code instead of object code.
I'd also have to tell it to generate code that conforms to the Linux C++ ABI. The problem is, Microsoft's compiler doesn't know how to do that, or how to call Linux syscalls, or how to mangle names so you'd be able to call native C++ libraries, or how to throw exceptions correctly, and I'm probably missing something.
Sure, you'd be able to futz with the uncommented assembly code by hand to make it work, but doing it automatically as part of a predictable build process is a very hard problem.
Couldn't get it to install. The .Net framework install bombs.
It might be possible to run in under Wine to cross compile Windows applications. I'd expect it to be very hard to impossible to convert VC++ created object files to anything that would can be linked to create a Linux app.
Then we just need a version of Autoconf that builds a makefile for the compiler of your choice (gcc, icc, or mscc).
The last thing we need is another version of autoconf.
I should mention that Dev-C++ uses the GNU toolchain as its back end, and won't work with the Borland compiler. You should probably consider using a more standards compliant compiler for school work, anyway.
You could try Dev-C++