"The LCDs got these awful lines or would just go black."
That's identical to the problem I've had, both times. I can't afford to have a laptop that cuts out on me every 1.5 months, so I won't be buying another Apple laptop.
Couldn't they at least put a password on the FTP site? They're not obligated under the GPL to distribute the source for free, and if they were just really slow to respond to requests for it, then it wouldn't be a clear cut violation. Not as clear cut as this anyway.
"But yes, good crypto is HARD to write and HARD to identify flaws in. This obvious fact seems to sometimes escape cryptographers when they review inexpertly created crypto software, who lament endlessly that people get it wrong, and sometimes get sufficiently exasperated to even identify the flaws in comprehensible terms. "This code listing should be self explanatory" being a key sin here."
It's on a crypto mailing list... I don't think it's unfair to assume readers will know what he's talking about. Not his fault it got posted to slashdot.
I see the sense of elitism in the crypto community, but I think it's completely justified. It's not great for PR, but crypto is really, really hard. Professional cryptographers can't even do a good job without a lot of peer review. Hobbyist crypto shouldn't be regarded as more secure than plaintext, IMO.
"Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised."
I think the way you can't write past the bounds of buffers is the primary thing he's talking about.
No reason you couldn't write a library for C to make it do basically the same thing. It would take the form of function calls/macros instead of changing the syntax, but that's okay.
Hardware can help, most modern hardware can do non-executable memory, but it's a pain to use properly, so most OSes don't. It's not enough by itself though, look at the X-Box.
The C libraries don't help. Take a look at some of the documentation. "the results are undefined" appears about a thousand times in the standard library. That basically means whoever implements that function isn't obligated to check for certain conditions, and every time that happens it's an exploit waiting to happen.
That's bad, and that leads to enough exploits by itself, but then you have just about every programmer on the planet doing stuff like this:
char buff[100];/* should be big enough */
"should be big enough" translates idiomatically as "please exploit me".
If you're using lsh, you've accepted that the people developing the software have a policy of releasing source code patches (many of which make working exploits a lot easier to write), and of releasing example exploit code when it exists. If you don't like it, closed source solutions are available. The exploit code won't work against any of the other SSH servers, including the commercial ones.
"On the other hand, I wonder if there is any point at all in producing another open source ssh implementation for the same problem space."
I'm in favor or diversity in general, but for me personally, asking me to use lsh is like asking me to bet against Theo's paranoia and attention to detail.
"No one in the real world gives a toss that openssh uses a BSD style licence."
On the contrary, OpenSSH gets used in places where a GNU licensed program would be difficult because it would have to be distributed on different media.
Altivec can't do double precision floats. The G5 has plenty of double precision power, but it's not in altivec. Dunno what they're going to be calculating, that may or may not not hurt.
"Re: Chassis"
Opteron cases have been available for many months. As have the Opterons, in point of fact. Months before this cluster got delivered, you could go to several stores in my city and buy a complete dual processor opteron system off the shelf, and OEMs have been selling workstation and rackmount systems.
They were probably taking bids on this a long time ago, and if it was before Opteron systems were available, it was also certainly before Apple had more than engineering samples of the G5's.
"Re: OS X"
It's not 64-bit, but I believe even the 32-bit versions of the OS could handle more than 4 gigs.
"and the OS has *always* been able to manipulate 128 bit data, as well as 64 bit data."
...? That's a non issue. The OS doesn't get involved with data in that way. The OS might provide libraries to help, but they don't do anything you couldn't do in assembly by yourself. You can use any (supported, non-privileged) instructions you want in a program. On OS X, Linux, Windows, whatever.
A lot of scientific computing uses double precision floats, which altivec doesn't do. The G5 has enough double precision power to handle it quite capably, but it doesn't use altivec.
"I'm still trying to figure out what the whole point of C# is. It's similar to Java, but it is not cross platform, but it's not as quick as a truly native app written in VB or C++."
It is cross platform, for some definitions of platform.
Microsoft saw IA-64 and x86-64. They knew most software would still be released x86 binaries only, and while the new architechtures would maintain binary compatability, something native would be better. This way allows them and everyone else to take advantage of a powerful new architechture without the additional development cost.
We compile a native binary on each system, they have a binary that'll run on any Windows. Really, it's a good solution if you assume you're dealing with people that don't want their source code getting out. The native binary has less overhead at runtime, but Windows has tons of overhead even without.NET.
Doesn't.NET cache a native optimized copy of the binary anyway? I read something about that but I don't remember if they actually did it.
Well it doesn't really have to be NFS. There's a network block driver that someone posted a link to, but it looked a bit heavyweight for such a tiny box. If you're doing it exclusively over the wired network and do some rudimentry authentication, it should be fairly secure without any encryption.
I'm more of an OpenBSD guy than a Linux guy, but can't you get NFS support with a module?
"Upon completion of the installation, you will have a system with basic tools such as syslog, telnetd, httpd (with cgi-bin support), vi, snort, mount, insmod, rmmod, top, grep, etc."
I imagine insmod is there so you can extend the kernel without flashing anything. I really have no idea what can be a module, but there's at least some freedom there.
Darwin (and therefore MacOS X) is based on the Mach kernel. It probably has FreeBSD code, and they make efforts to make it FreeBSD compatable in some respects, but it's only loosely related.
I've never quite understood how the BSD people can think they've got freedom when their work may be locked down and stolen by a corporation any time.
You don't understand the BSD license. It's impossible to steal something that's given freely. BSD has been such a seminal influence precisely because the code can be "stolen". That's the intent.
Besides, AT&T did try to steal (in the "you can't use it anymore" sense of the word) BSD's code. They lost.
If he thinks separating from the protection granted by GPL will further the survivability of OpenBSD, he's seriously mistaken.
BSD predates the GPL.
Re:Opcode depreciation
on
AMD64 Preview
·
· Score: 1
hmmmm
I can think of two things. I've no doubt it's been published, but I really don't feel like looking. If I'm wrong, someone will correct me.
1) They simply set up the microcode with assumptions that slow down old opcodes and speed up common ones.
2) Attempting to run one of those opcodes will trigger an exception that that's handled by software. This is done with some instructions on SPARC/Solaris.
The only work that you legally have the right to distribute without having to purchase a right, is original work which you personally have composed or work that is in the public domain
Slashdot Mirror
I'm not a Linux user, but couldn't you set up multiple root partitions and dual boot with them?
"The LCDs got these awful lines or would just go black."
That's identical to the problem I've had, both times. I can't afford to have a laptop that cuts out on me every 1.5 months, so I won't be buying another Apple laptop.
I've had 2 bad power adapters, 2 bad motherboards, and bad memory for my iBook. Which I got in March.
That's less than a month and a half between problems, on average. It's been a real pleasure.
They've honored the warantee at least.
Couldn't they at least put a password on the FTP site? They're not obligated under the GPL to distribute the source for free, and if they were just really slow to respond to requests for it, then it wouldn't be a clear cut violation. Not as clear cut as this anyway.
"But yes, good crypto is HARD to write and HARD to identify flaws in. This obvious fact seems to sometimes escape cryptographers when they review inexpertly created crypto software, who lament endlessly that people get it wrong, and sometimes get sufficiently exasperated to even identify the flaws in comprehensible terms. "This code listing should be self explanatory" being a key sin here."
It's on a crypto mailing list... I don't think it's unfair to assume readers will know what he's talking about. Not his fault it got posted to slashdot.
I see the sense of elitism in the crypto community, but I think it's completely justified. It's not great for PR, but crypto is really, really hard. Professional cryptographers can't even do a good job without a lot of peer review. Hobbyist crypto shouldn't be regarded as more secure than plaintext, IMO.
"Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised."
I think the way you can't write past the bounds of buffers is the primary thing he's talking about.
No reason you couldn't write a library for C to make it do basically the same thing. It would take the form of function calls/macros instead of changing the syntax, but that's okay.
The C libraries don't help. Take a look at some of the documentation. "the results are undefined" appears about a thousand times in the standard library. That basically means whoever implements that function isn't obligated to check for certain conditions, and every time that happens it's an exploit waiting to happen.
That's bad, and that leads to enough exploits by itself, but then you have just about every programmer on the planet doing stuff like this:
"should be big enough" translates idiomatically as "please exploit me".
If you're using lsh, you've accepted that the people developing the software have a policy of releasing source code patches (many of which make working exploits a lot easier to write), and of releasing example exploit code when it exists. If you don't like it, closed source solutions are available. The exploit code won't work against any of the other SSH servers, including the commercial ones.
"On the other hand, I wonder if there is any point at all in producing another open source ssh implementation for the same problem space."
I'm in favor or diversity in general, but for me personally, asking me to use lsh is like asking me to bet against Theo's paranoia and attention to detail.
"No one in the real world gives a toss that openssh uses a BSD style licence."
On the contrary, OpenSSH gets used in places where a GNU licensed program would be difficult because it would have to be distributed on different media.
"Re: Processors"
...? That's a non issue. The OS doesn't get involved with data in that way. The OS might provide libraries to help, but they don't do anything you couldn't do in assembly by yourself. You can use any (supported, non-privileged) instructions you want in a program. On OS X, Linux, Windows, whatever.
Altivec can't do double precision floats. The G5 has plenty of double precision power, but it's not in altivec. Dunno what they're going to be calculating, that may or may not not hurt.
"Re: Chassis"
Opteron cases have been available for many months. As have the Opterons, in point of fact. Months before this cluster got delivered, you could go to several stores in my city and buy a complete dual processor opteron system off the shelf, and OEMs have been selling workstation and rackmount systems.
They were probably taking bids on this a long time ago, and if it was before Opteron systems were available, it was also certainly before Apple had more than engineering samples of the G5's.
"Re: OS X"
It's not 64-bit, but I believe even the 32-bit versions of the OS could handle more than 4 gigs.
"and the OS has *always* been able to manipulate 128 bit data, as well as 64 bit data."
A lot of scientific computing uses double precision floats, which altivec doesn't do. The G5 has enough double precision power to handle it quite capably, but it doesn't use altivec.
sshd is hard to part with. Leaving it switched on on all my systems typically saves my ass several times a year.
Even after the last few days, it's still a good bet.
"I'm still trying to figure out what the whole point of C# is. It's similar to Java, but it is not cross platform, but it's not as quick as a truly native app written in VB or C++."
.NET.
.NET cache a native optimized copy of the binary anyway? I read something about that but I don't remember if they actually did it.
It is cross platform, for some definitions of platform.
Microsoft saw IA-64 and x86-64. They knew most software would still be released x86 binaries only, and while the new architechtures would maintain binary compatability, something native would be better. This way allows them and everyone else to take advantage of a powerful new architechture without the additional development cost.
We compile a native binary on each system, they have a binary that'll run on any Windows. Really, it's a good solution if you assume you're dealing with people that don't want their source code getting out. The native binary has less overhead at runtime, but Windows has tons of overhead even without
Doesn't
Implicit in the "No one is free to break the law." argument is the "If you're not doing anything illegal, then you have nothing to hide." argument.
No thanks.
Well it doesn't really have to be NFS. There's a network block driver that someone posted a link to, but it looked a bit heavyweight for such a tiny box. If you're doing it exclusively over the wired network and do some rudimentry authentication, it should be fairly secure without any encryption.
I'm more of an OpenBSD guy than a Linux guy, but can't you get NFS support with a module?
"Upon completion of the installation, you will have a system with basic tools such as syslog, telnetd, httpd (with cgi-bin support), vi, snort, mount, insmod, rmmod, top, grep, etc."
I imagine insmod is there so you can extend the kernel without flashing anything. I really have no idea what can be a module, but there's at least some freedom there.
Can't you use a file on an NFS mount with the loopback driver to get a swap device?
I'm not sure what the point would be... if you have another box, why not just run your services on it... but they nifty value is significant.
OpenBSD has it on most architechtures as of 3.3, and i386 has it in the CURRENT tree, so it'll be included in 3.4 AFAIK.
I don't know what the other BSD's are doing about it. It takes a fair bit of work in the kernel, so it's not a straight port.
OpenBSD zealots, GPL zealots, MacOS X zealots...
There's a lot of cults to choose from.
Darwin (and therefore MacOS X) is based on the Mach kernel. It probably has FreeBSD code, and they make efforts to make it FreeBSD compatable in some respects, but it's only loosely related.
I've never quite understood how the BSD people can think they've got freedom when their work may be locked down and stolen by a corporation any time.
You don't understand the BSD license. It's impossible to steal something that's given freely. BSD has been such a seminal influence precisely because the code can be "stolen". That's the intent.
Besides, AT&T did try to steal (in the "you can't use it anymore" sense of the word) BSD's code. They lost.
If he thinks separating from the protection granted by GPL will further the survivability of OpenBSD, he's seriously mistaken.
BSD predates the GPL.
hmmmm
I can think of two things. I've no doubt it's been published, but I really don't feel like looking. If I'm wrong, someone will correct me.
1) They simply set up the microcode with assumptions that slow down old opcodes and speed up common ones.
2) Attempting to run one of those opcodes will trigger an exception that that's handled by software. This is done with some instructions on SPARC/Solaris.
The only work that you legally have the right to distribute without having to purchase a right, is original work which you personally have composed or work that is in the public domain
Exactly. I'm a leech. Your point?
How about records from the security cameras?
...
You mean it was all stored on the hard drives of the stolen computers?