Yup. Very nice device for ssh use. Software still has a few bugs (== random reboots), which aren't getting fixed. The navikey joystick thing also breaks quite easily (I'm currently on my third E70 in 18 months, fortunately the warranty is two years:) ). Still, it has a real keyboard and the screen is big enough for a reasonably sized terminal (with a smallish font, but I have good eyes;) ). Means I don't _have_ to carry a laptop around.
As usual with Linux, at the time slashdot picks the story up, the problem has been fixed for some time (10 days ago in Linus' tree, in various test trees quite a bit longer):
Hmn. Might not be the same, but... We had a PERC5/i SAS RAID controller and the performance was awful, FC6, CentOS4, slow in both. As if "everything" stopped after a disk operation on the system.
Rebuilt the array and everything started working a-ok (300MB/s RAID-5 writes to the array etc.).
The criminal underground (russian mafia etc.) supposedly pay $50k-$100k for zero-days, if you're after the money might as well sell your exploit to them.
If you're after fame, you report it through the proper channels (CERT or the vendor directly). You get credited in the bugfix, but gain no money at all.
Selling to one of these guys just goes into the pockets of these zero-day vendors, who then get more customers paying them $$$ to be a few days ahead of everyone else (but they'll get the patches at the same time as anyone else anyway, their IDS's just get signatures for these new exploits)
As a coworker of the winning team, the main reason for doing an appliance version (apart from participating in this contest) was packaging. We actually do have a "native" windows port of the code (using python, pygtk etc.), and it's about 25 MB zipped when containing all the dependancies, of which there is really way too many to ask a random user to install so it all has to be packaged into the same thing, really.
The vmware image is about 72 MB bzip2-compressed which includes a stripped-down Ubuntu, X11 etc. And it runs on Windows, any random Linux distro that might have an old pygtk/cairo/whatnot that doesn't work with our code, OS X (with OS X vmware) out of the box. Nice even if you do lose some performance and run into issues inherent to virtualization (accurate timestamps and promiscuous mode inside the virtual machine are tricky and do have limitations!).
We mostly run and develop it natively ourselves (on FC5 and OS X), yet we run into "AAARGH! How do I get a new enough Y for OS X to run this" discussions every week or so.
Still some other hardware in there with no specs, tho. ATI used to be very good in releasing docs, but there's nothing for the latest stuff. At least they have their own proprietary driver, but you're pretty much stuck with it forever...
Typically not. Well, not all buffer overflows make code-execution possible, but with a smart enough exploiter quite a few things can, it's just not as straightforward... For a security researcher writing an exploit doesn't make much sense. The bug is there, the software crashes and should be fixed. Anything beyond that just helps the bad guys and takes lots of precious time.
Mind you, the original page does say
"Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.". Anything beyond that is just journalist speculation:-)
Developing new drugs is not cheap. It need not be, but the truth is, that when a drug makes it to the market, the company inventing it has spent millions on it. If they fuck up and there's some horrendous side-effects that were not uncovered in trials, one would expect them to be liable for it, and be able to sue them for millions as well. Most of this is uncovered in trials, but mistakes happen. A lot of the (basic) research is done with public funding, but in the end, it is the company that brings stuff to the market that bears the risk.
Or one might choose to make it all public sector, have all drugs cheap and available for everyone. But if things go wrong, expecting millions if some drug ruins the rest of your life is not really realistic.
I value human life above anything else, but we really can't get the best of both worlds.
Would be great. The baggage allowances will probably be horribly low (as in ~= none), though. But a credit card, passport and toothbrush are all you need anyway:) Then just take a nice business class commercial airplane back to carry all the stuff you bought back home.
Anonymous Diffie-Hellman would be "good enough"
on
VoIP Security
·
· Score: 2, Insightful
I mean, negotiating a private key between two hosts is trivial, just use the good old DH key exchange thing. Could even use IPSEC for the actual encryption, no need to reinvent the wheel and add crypto to the VOIP protocols, just do those security associations when you setup a call.
The downside is, that a MITM is possible to get the key, but that's pretty damn unlikely compared to people just sniffing and listening to your call or blindly injecting data to an existing one. From what information is available about Skype, it does something like this, I believe.
But, designing horribly complicated systems that cover the corner cases seems to be the norm, and those get ignored due to complexity and thus everyone does the unencrypted thing in the end:(
They claim -Os is to remove bloat, not increase performance:-) Thing is, for kernel type code the resulting code is actually _faster_ than with gcc -O2, since there is a lot less cache pressure.
The Fedora kernel people have benchmarked this quite a bit (and now compile kernels with -Os too), the difference is quite measurable, 5%:ish in some benchmarks.
First they take your money (My Money - Microsoft Money!), then they take your computer. But remember kids, as long as you use Free Software THEY CAN NEVER TAKE YOUR LIBERTY!
Which is obviously a microbenchmark that doesn't measure real-life application performance. But having a small thing that gets done quite often (context switches) take 4x more time or so does translate into real-life performance losses too (obviously not 4x, but still measurable).
You might be able to "hide" all the low-level performance losses by optimizing elsewhere, but it still doesn't mean you're doing the best possible thing.
There's absolutely no reason to carry around a dinosaur like Mach around. Portability isn't a reason (see number of platforms supported by Linux and NetBSD vs. Darwin). Scalability isn't one either.
Pathscale, Sun Studio 10. Both are great (commercial) compilers. Only make sense for "scientific" code running on a bad-ass Opteron clusters, though, biggest benefit is the parallelization support. It's a somewhat different market too, gcc supports just about everything out there, which makes progress in some areas slow (The SSA stuff in gcc 4.0 helps, but it's just a foundation for cool stuff). And it's what people develop open source software for, even those people that don't know that much about writing portable code, so anything != gcc is a hassle.
AMD is also working with the GCC people too (including engineer hours on actually improving the code, I believe), there was a recent post on comp.arch about this.
Interestingly the issues seen in new Windows are the same as the ones in x86_64 Linux. Except drivers aren't nearly as problematic since there are only a few "3rd party" proprietary drivers (like graphics card manufacturers), and those have had 64-bit drivers for quite some time. The drivers in the kernel tree have been cleaned up during the last 10 years (starting with the alpha port), so in many cases just a recompile is enough.
(Browser) plugins are the other issue, if you need flash or proprietary format video playing using windows dll's you'll still want to use a 32-bit browser or video player. Konqueror, I believe, runs plugins as a separate process, so it's unaffected by this (it's not a bad design choice either, Firefox/mozilla/IE should do this too;), that way buggy browser plugins don't crash your browser completely).
So, do you need a 64-bit OS? Like mentioned in other comments, you probably don't need 64-bitness that much (unless running code processing lots of big numbers), but those extra registers you get in 64-bit mode give you a nice speed boost. And people already have enough memory in their boxes to see a benefit today (> 1GB is enough since you avoid all those TLB flushes and all that, this applies to Windows and Linux, >= 4GB for a big boost since you don't need that PAE crap)
TCP SACK was introduced in 1996. Linux introduced it some time between 2.0 and 2.2 (that is, around 1999-2000). It's quite useful if you have a high-bandwidth link with some packet loss, since you can now retransmit only those packets that actually did get lost.
Good to see that the we-are-the-defacto-internet-standard-tcpip-stack people are finally catching up. NetBSD does get some very impressive single-CPU TCP/IP benchmarks though. Oh. They forgot fine-grained locking in their network stack. I suppose performance with those quad Opterons sucks. Too bad. Well. they do have the long distance record tho, guess how many cpus those boxes had.:)
And yes. PAM is a pile of dung, even on non-BSD systems. But it does let you easily authenticate off just about anything adding just a few lines to your config files. That means RADIUS logins for local users or those that are just accessing some random web page served by Apache that you want to add some access control to. Or LDAP or Kerberos or NIS or NIS+ or a customized SQL database.
yum should be quite a bit faster in fc4test1, they've recently added a new xml parser (cElementTree) for the metadata which whips libxml2 ass (in fact, it's not much slower than reading plaintext in:))
Start releasing useful open source software for Windows that adds that Wine-specific key the Office update stuff is checking for into the registry and refuses to run without it. (obviously people can remove the check, it's open source after all, but that's not the point:-) )
Then watch poor people unable to install Office updates because they're not running a genuine version of Windows even when they are.
Get a Linksys WRT54G (no need for GS even, you're just going to use it for sniffing), stick openwrt on it, put kismet_drone on it and off you go. Gives you your wlan traffic over good old Ethernet, and costs something like $65 nowadays.
Or you can buy a $30-50 card for your PC which might or might not be able to do monitor mode depending on your drivers, and might or might not reliably go into monitor mode depending on the exact sequence of iwconfig/ifconfig/catting stuff into files in/proc you are doing and finally might or might not show you all the packets since the firmware hides them from you.
Of course if you're running around with a laptop the Linksys option is a bit tricky since you need to feed power to it. For basic indoor problem-solving it's unbeatable. Unless someone comes up with a reliable source for prism2.5/3's.
Still need to find a good 802.11a solution though.
Living in France for a year in 2000-2001 I had to file for taxes there. They had this Java-based software (with instructions on using it on Linux) that did the trick. Well, I still had to use the paper output it generated, I think if you had Minitel or whatnot you could file online too. I was impressed:-)
Here in Finland they know how much you earn anyway since your employer tells them, so they send you a "tax proposal", which is correct for "normal" people and they don't have to do anything other than possibly pay more/get a refund if the deductions their employer made weren't accurate. Anything special (like profits made from sales of stocks and investment funds, assets etc.) you can, depending on your bank, print out the correct forms online which takes a few minutes, return those and that's it. Of course it can get complicated here too, but I manage in less then an hour:-)
Every application compiled with gcc for x64_64 gets to use said registers. Every application compiled with Visual C++ for x86_64/EM-64T gets to use said registers. That includes Doom 5 or whatever the application is. Applications compiled with gcc -m32 or Visual C++ for 32-bit windows do NOT get to use those registers. Once Quake XYZ gets compiled with Visual C++/64 and gets x % more FPS, people will switch to whatever performs better. That's why I said Intel has to shape up before that happens. Since there's no huge 64 bit market there _NOW_ they still have time. Apart from Linux hobbyists and scientific computing.
40-45% is matlab simulating radio waves as well as a home-brew program for factorizing co-primes (primes I can fortunately factorize in my head!). Latter runs in 15 mins (2.4GHz Opteron), a 3.4GHz EM-64T uses half an hour and a normal 3Ghz Xeon about an hour. (4* less operations since it's really just multiplying big integers, really)
Also even with 4GB of RAM you get some of the benefits, in fact anything over 1GB is enough with current Linux/Windows versions to get some benefits. Ever heard about 1:3 kernel:user VM splits (same on all x86 OS's) and TLB flushes?
Feel free to discuss operating system or hardware architectures with me any time!
Should have been "That or Microsoft..." really. Once those 64bit FPSs start showing up for Windows, people will run whatever gives them the best framerate. Until then, whatever happens in the 64bit mode is irrelevant apart from the Linux market.
Slashdot Mirror
Yup. Very nice device for ssh use. Software still has a few bugs (== random reboots), which aren't getting fixed. The navikey joystick thing also breaks quite easily (I'm currently on my third E70 in 18 months, fortunately the warranty is two years :) ). ;) ). Means I don't _have_ to carry a laptop around.
Still, it has a real keyboard and the screen is big enough for a reasonably sized terminal (with a smallish font, but I have good eyes
As usual with Linux, at the time slashdot picks the story up, the problem has
been fixed for some time (10 days ago in Linus' tree, in various test trees quite a bit longer):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f09e495df27d80ae77005ddb2e93df18ec24d04a
Hmn. Might not be the same, but... We had a PERC5/i SAS RAID controller and the performance was awful, FC6, CentOS4, slow in both. As if "everything" stopped after a disk operation on the system.
Rebuilt the array and everything started working a-ok (300MB/s RAID-5 writes to the array etc.).
The criminal underground (russian mafia etc.) supposedly pay $50k-$100k for zero-days, if you're after the money might as well sell your exploit to them.
If you're after fame, you report it through the proper channels (CERT or the vendor directly). You get credited in the bugfix, but gain no money at all.
Selling to one of these guys just goes into the pockets of these zero-day vendors, who then get more customers paying them $$$ to be a few days ahead of everyone else (but they'll get the patches at the same time as anyone else anyway, their IDS's just get signatures for these new exploits)
As a coworker of the winning team, the main reason for doing an appliance version (apart from participating in this contest) was packaging. We actually do have a "native" windows port of the code (using python, pygtk etc.), and it's about 25 MB zipped when containing all the dependancies, of which there is really way too many to ask a random user to install so it all has to be packaged into the same thing, really.
The vmware image is about 72 MB bzip2-compressed which includes a stripped-down Ubuntu, X11 etc. And it runs on Windows, any random Linux distro that might have an old pygtk/cairo/whatnot that doesn't work with our code, OS X (with OS X vmware) out of the box. Nice even if you do lose some performance and run into issues inherent to virtualization (accurate timestamps and promiscuous mode inside the virtual machine are tricky and do have limitations!).
We mostly run and develop it natively ourselves (on FC5 and OS X), yet we run into "AAARGH! How do I get
a new enough Y for OS X to run this" discussions every week or so.
Of course, missing specs just means someone has to reverse-engineer: http://bcm43xx.berlios.de/
Still some other hardware in there with no specs, tho. ATI used to be very good in releasing docs, but there's nothing for the latest stuff. At least they have their own proprietary driver, but you're pretty much stuck with it forever...
Typically not. Well, not all buffer overflows make code-execution possible, but with a smart enough exploiter quite a few things can, it's just not as straightforward... For a security researcher writing an exploit doesn't make much sense. The bug is there, the software crashes and should be fixed. Anything beyond that just helps the bad guys and takes lots of precious time.
:-)
Mind you, the original page does say
"Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.". Anything beyond that is just journalist speculation
Developing new drugs is not cheap. It need not be, but the truth is, that when a drug makes it to the market, the company inventing it has spent millions on it. If they fuck up and there's some horrendous side-effects that were not uncovered in trials, one would expect them to be liable for it, and be able to sue them for millions as well. Most of this is uncovered in trials, but mistakes happen. A lot of the (basic) research is done with public funding, but in the end, it is the company that brings stuff to the market that bears the risk.
Or one might choose to make it all public sector, have all drugs cheap and available for everyone. But if things go wrong, expecting millions if some drug ruins the rest of your life is not really realistic.
I value human life above anything else, but we really can't get the best of both worlds.
Just remember to bring your uncursed pack of cigarettes +0 with you when playing these games. -1 to constitution, but +5 to sanity :D
Would be great. The baggage allowances will probably be horribly low (as in ~= none), though. But a credit card, passport and toothbrush are all you need anyway :) Then just take a nice business class commercial airplane back to carry all the stuff you bought back home.
I mean, negotiating a private key between two hosts is trivial, just use the good old DH key exchange thing. Could even use IPSEC for the actual encryption, no need to reinvent the wheel and add crypto to the VOIP protocols, just do those security associations when you setup a call.
:(
The downside is, that a MITM is possible to get the key, but that's pretty damn unlikely compared to people just sniffing and listening to your call or blindly injecting data to an existing one. From what information is available about Skype, it does something like this, I believe.
But, designing horribly complicated systems that cover the corner cases seems to be the norm, and those get ignored due to complexity and thus everyone does the unencrypted thing in the end
Yea right...
:-) ).
Linux has been booting on EFI Itanium boxes since the beginning, even before there was a 64-bit Windows (outside MSFT labs, that is
EFI is certainly not pretty, but it's still a great improvement.
They claim -Os is to remove bloat, not increase performance :-) Thing is, for kernel type code the resulting code is actually _faster_ than with gcc -O2, since there is a lot less cache pressure.
The Fedora kernel people have benchmarked this quite a bit (and now compile kernels with -Os too), the difference is quite measurable, 5%:ish in some benchmarks.
See the following: http://www.microsoft.com/money/support/manual/scre ens/fig5-2.jpg
First they take your money (My Money - Microsoft Money!), then they take your computer.
But remember kids, as long as you use Free Software
THEY CAN NEVER TAKE YOUR LIBERTY!
Hayden Christensen graduated from the William Shatner school of melodrama. With honors.
See http://www.khaaan.com/ for further explanation.
Darwin still sucks in lmbench, sorry.b rary/l-y dlg5.html)
(http://www-106.ibm.com/developerworks/li
Which is obviously a microbenchmark that doesn't measure real-life application performance. But having a small thing that gets done quite often (context switches) take 4x more time or so does translate into real-life performance losses too (obviously not 4x, but still measurable).
You might be able to "hide" all the low-level performance losses by optimizing elsewhere, but it still doesn't mean you're doing the best possible thing.
There's absolutely no reason to carry around a dinosaur like Mach around. Portability isn't a reason (see number of platforms supported by Linux and NetBSD vs. Darwin). Scalability isn't one either.
Pathscale, Sun Studio 10. Both are great (commercial) compilers. Only make sense for "scientific" code running on a bad-ass Opteron clusters, though, biggest benefit is the parallelization support. It's a somewhat different market too, gcc supports just about everything out there, which makes progress in some areas slow (The SSA stuff in gcc 4.0 helps, but it's just a foundation for cool stuff). And it's what
people develop open source software for, even those people that don't know that much about writing portable code, so anything != gcc is a hassle.
AMD is also working with the GCC people too (including engineer hours on actually improving the code, I believe), there was a recent post on comp.arch about this.
Interestingly the issues seen in new Windows are the same as the ones in x86_64 Linux. Except drivers aren't nearly as problematic since there are only a few "3rd party" proprietary drivers (like graphics card manufacturers), and those have had 64-bit drivers for quite some time. The drivers in the kernel tree have been cleaned up during the last 10 years (starting with the alpha port), so in many cases just a recompile is enough.
;), that way buggy browser plugins don't crash your browser completely).
(Browser) plugins are the other issue, if you need flash or proprietary format video playing using windows dll's you'll still want to use a 32-bit browser or video player. Konqueror, I believe, runs plugins as a separate process, so it's unaffected by this (it's not a bad design choice either, Firefox/mozilla/IE should do this too
So, do you need a 64-bit OS? Like mentioned in other comments, you probably don't need 64-bitness that much (unless running code processing lots of big numbers), but those extra registers you get in 64-bit mode give you a nice speed boost. And people already have enough memory in their boxes to see a benefit today (> 1GB is enough since you avoid all those TLB flushes and all that, this applies to Windows and Linux, >= 4GB for a big boost since you don't need that PAE crap)
TCP SACK was introduced in 1996. Linux introduced it some time between 2.0 and 2.2 (that is, around 1999-2000). It's quite useful if you have a high-bandwidth link with some packet loss, since you can now retransmit only those packets that actually did get lost.
:)
Good to see that the we-are-the-defacto-internet-standard-tcpip-stack people are finally catching up. NetBSD does get some very impressive single-CPU TCP/IP benchmarks though. Oh. They forgot fine-grained locking in their network stack. I suppose performance with those quad Opterons sucks. Too bad. Well. they do have the long distance record tho, guess how many cpus those boxes had.
And yes. PAM is a pile of dung, even on non-BSD systems. But it does let you easily authenticate off just about anything adding just a few lines to your config files. That means RADIUS logins for local users or those that are just accessing some random web page served by Apache that you want to add some access control to. Or LDAP or Kerberos or NIS or NIS+ or a customized SQL database.
yum should be quite a bit faster in fc4test1, they've recently added a new xml parser (cElementTree) for the metadata which whips libxml2 ass (in fact, it's not much slower than reading plaintext in :))
Start releasing useful open source software for Windows that adds that Wine-specific key the Office update stuff is checking for into the registry and refuses to run without it. (obviously people can remove the check, it's open source after all, but that's not the point :-) )
Then watch poor people unable to install Office updates because they're not running a genuine version of Windows even when they are.
Get a Linksys WRT54G (no need for GS even, you're just going to use it for sniffing), stick openwrt on it, put kismet_drone on it and off you go. Gives you your wlan traffic over good old Ethernet, and costs something like $65 nowadays.
/proc you are doing and finally might or might not show you all the packets since the firmware hides them from you.
Or you can buy a $30-50 card for your PC which might or might not be able to do monitor mode depending on your drivers, and might or might not reliably go into monitor mode depending on the exact sequence of iwconfig/ifconfig/catting stuff into files in
Of course if you're running around with a laptop the Linksys option is a bit tricky since you need to feed power to it. For basic indoor problem-solving it's unbeatable. Unless someone comes up with a reliable source for prism2.5/3's.
Still need to find a good 802.11a solution though.
Living in France for a year in 2000-2001 I had to file for taxes there. They had this Java-based software (with instructions on using it on Linux) that did the trick. Well, I still had to use the paper output it generated, I think if you had Minitel or whatnot you could file online too. I was impressed :-)
:-)
Here in Finland they know how much you earn anyway since your employer tells them, so they send you a "tax proposal", which is correct for "normal" people and they don't have to do anything other than possibly pay more/get a refund if the deductions their employer made weren't accurate. Anything special (like profits made from sales of stocks and investment funds, assets etc.) you can, depending on your bank, print out the correct forms online which takes a few minutes, return those and that's it. Of course it can get complicated here too, but I manage in less then an hour
Duh...
Every application compiled with gcc for x64_64 gets to use said registers. Every application compiled with Visual C++ for x86_64/EM-64T gets to use said registers. That includes Doom 5 or whatever the application is. Applications compiled with gcc -m32 or Visual C++ for 32-bit windows do NOT get to use those registers. Once Quake XYZ gets compiled with Visual C++/64 and gets x % more FPS, people will switch to whatever performs better. That's why I said Intel has to shape up before that happens. Since there's no huge 64 bit market there _NOW_ they still have time. Apart from Linux hobbyists and scientific computing.
40-45% is matlab simulating radio waves as well as a home-brew program for factorizing co-primes (primes I can fortunately factorize in my head!). Latter runs in 15 mins (2.4GHz Opteron), a 3.4GHz EM-64T uses half an hour and a normal 3Ghz Xeon about an hour. (4* less operations since it's really just multiplying big integers, really)
Also even with 4GB of RAM you get some of the benefits, in fact anything over 1GB is enough
with current Linux/Windows versions to get some benefits. Ever heard about 1:3 kernel:user VM splits (same on all x86 OS's) and TLB flushes?
Feel free to discuss operating system or hardware architectures with me any time!
Should have been "That or Microsoft..." really.
Once those 64bit FPSs start showing up for Windows, people will run whatever gives them the best framerate. Until then, whatever happens in the 64bit mode is irrelevant apart from the Linux market.