Don't get all worked up, guys. Executable files that can modify other executable files to self-replicate are nothing new, and.NET is not "insecure" because viruses can be written for it. (Though it may be insecure for many other reasons!;)) Linux has viruses too. The real question is how much damage such code can do once it's run -- on multi-user systems with permissions like linux and NT, presumably this is not much.
(Regardless, kudos to the creator for the cool hack and for not unleashing it on the world!)
Personally, I think the idea of high-level languages and portable binaries is a good one, so I am actually excited about the Common Language Runtime (etc.) aspect of.NET. I hate hate hate the web services and passport bit, though...
> Would you start a game of monopoly in the $2000 or
> $3000/$4000 scenario?
> True, but Monopoly is a zero-sum game, while the
> economy is not.
Actually, that's not true. Again, it depends on what your evaluation function is, but unless it is "the winner gets 1 point, the loser gets -1 points", it is not zero-sum. That's because of the "chance" and "community chest" cards (and passing Go). In fact, a cooperative game of monopoly could easily go on forever, with both players accumulating massive wealth.
> But more important than a chance to poke at Lefties
> is the extreme implications of this: Is perceived
> fairness really a more important survival trait
> than unfair 'growth' scenarios? Clearly not, if
> everyone gains, even unequally, the group as a
> whole does better and the individuals do better as
> well. A win/win.
In my experience it is often the *disparity* in wealth rather than the actual magnitude of wealth that matters. If your evaluation function is "number of dollars posessed", then you are correct, but I think that is a little bit too glib.
Would you start a game of monopoly in the $2000 or $3000/$4000 scenario?
Just as I'll claim if you try to use traditional economic arguments to justify "ownership" of software, or whatever, analogies between physical property (money) and property that can be duplicated (software, information) just don't hold up. The fact that you can share software or information with a friend without losing it yourself makes a HUGE difference in any kind of economic game. (There is some cost, for instance bandwidth in a peer-to-peer system, but I think it is mostly negligible.)
However, I would expect that this result does in fact hold for IP-less software economies as well. I am just saying that making direct comparisons is always trouble.
I'm thinking more of the cost of upgrading an inventory system or something designed for Windows NT when Microsoft decides that a company needs to upgrade and won't support NT any more. I saw this kind of thing a lot at the place I worked a few years ago -- a business would be totally happy with their setup, but forced to upgrade because the product (or OS) was being phased out (or at that time, because of dubious Y2K warnings).
At least, that's what I thought Robertson was aiming for. Like I said though, it'll be a tough sell...
> The business community are unlikely to - why would
> a sysadmin decide to put his neck on the line
> switching 5000 systems to lindows. When one
> critical application doesn't work as it's meant
> to, it all come crashing down around him. Most
> sysadmins will just stick to windows even if it
> does cost more.
I doubt that a sysadmin would switch of his own volition (unless it was a small shop), but often these kinds of decisions are made by management. They do care about the cost of software, and if Lindows.com can market it well, they might go for it.
I agree that it will be a tough sell, though. Let's hope that the Wine project can get a lot of good code out of it...
You're wrong about this. I won't try to convince you about subjective things, like it being "easier to use" (but really, 3000 lines to 24,000 lines should speak something...), but I want to clear up your misunderstandings:
1. Since algorithmic changes can make such a difference, if you read the page closely you'll see that some of the benchmarks are "same way" benchmarks, some of them are "same thing" benchmarks. "same way" ones specify an algorithm and make you implement it that way. The fibonacci one is like that, not because the author doesn't know that you can use an accumulator or memoization, but because he wants to test the speed of that style of recursion. There is NOTHING about SML that makes you unable to easily write an efficient (algorithmically and instruction-level) fibonacci function.
Here, I really want to prove this to you, so I ran mlton (a fast ML compiler for linux) on the following code for factorial (the same accumulator technique applies to fib, and it's the way you'd want to write the function):
(* fact (n,a) with n >= 0 gives a * (n!) *)
fun fact (0,acc) = acc
| fact (n,acc) = fact (n - 1, n * acc)
Here is the (important part of) the assembly code you get out:
GCC did a really nice job with this one, the main differences being the block layout and register allocation. I don't even know if using the stack instead of registers is a big deal on the x86, since I seem to recall that it will make pseudo-registers out of stack slots. Either way, these are both back-end issues that could be fixed (the mlton native backend is only a few months old); they don't have anything to do with fundamental properties of the language.
SML is coming in at something like half the speed of C at best on almost all of them, and in most cases far far worse than that.
All right, I think this is a real exaggeration, so I really have to call your bluff on this one. I went and compared all of the tests. SML, is in these benchmarks, on average, 1.91x slower than than C. O'caml is 1.44 times slower. At best, SML is 5.88 times faster than C, at worst, 5.22 times slower (it does badly in the highly array-intensive code like matrix multiplication because of bounds checking). O'Caml is at best 4.5 times faster than C, at worst, only 2.65 times slower. (I wish I had also tabulated g++; but my guess is that it falls around where SML is.)
So, even if you hate SML, I hope you will reconsider your notion that it is inefficient!
Of course, I still maintain that actual program speed is meaningless for network servers (how many CPU seconds has your ftp server used?). Having 0 buffer overflows is extremely meaningful, though, and *that* would get linux a reputation as a secure OS.
I should clarify; didn't really mean features, but library functionality. Try writing an SML GUI for X.
Well, there are GTK bindings and stuff, but I'll agree that library support is not good for interactive apps. For writing network servers, library support is just fine, and it is easy to interface to C libraries.
> but there's still no excuse for using SML as
> opposed to coding in C using safe I/O routines. I
> know this is supposed to be one of the few areas
> its supporters claim it to be good at...
The 'excuses' are:
1. C does not have safety. As shown again and again, network apps written in C have security holes in them. (Safety is really nice, even not just for security.)
2. It's an awful lot easier to write software in high level languages, SML being a good example
3. SML is actually very fast. Maybe you used it a long while ago, or were confused by the interactive system (where compilation is part of running your program), but it is fast, I promise. Check out the benchmarks. http://www.bagley.org/~doug/shootout/craps.shtml
By the way, 'safe' IO routines are not going to do it for you alone -- security problems can be caused by many of the unsafe aspects of C. (For instance, netscape once had an exploitable heap-corruption vulnerability in its JPEG parser, and wu_ftpd recently had a globbing bug via libc that could be exploited through malloc.)
> It encourages inefficient programming
> techniques (such as recursion) and lacks a hell
> of a lot of important features - not to mention
> that by implementing a non-procedural
> programming paradigm it becomes uselessly
> high-level (bad to translate into assembly
Well, I don't know what useful features it's missing (it has every useful feature of C that I know of, for instance), but the other things you say are basically wrong. Recursion is not inefficient in SML, nor need it be in other languages. In fact, most SML compilers will compile a tail-recursive function into a JMP, just like a loop in C. I don't know what you mean by it being "bad to translate into assembly language", but people seem to have a fine time doing it, and producing nice fast code! Sure, it is higher level, so a compiler is more complicated, but the compiler can also take advantage of that to do more optimization.
> but honestly, speaking as someone who has spent
> far more of his life working on it than he would
> have liked, its obscurity is well-deserved.
Well, all I can say in its defense is that I hated SML too when I had my undergraduate course in it. But at that point I was just immature, and after I gave it more time, I really think it is great now. I do understand it being unfamiliar though, believe me. (That's why I suggested Java as a modern language that's C-ish, even though I don't think Java is that great.)
Mac OS X, which is about the only modern desktop OS
I can think of that uses a microkernel, has been
badly slated for its performance by a number of
people, and I would be surprised if their decision
to opt for the Mach kernel was not at least partly
to blame.
That may be true. I actually think it's all of the fancy GUI stuff that makes it seem slow, but I don't have any way to back that up. I do believe that performance of the kernel itself (except for a few very important parts) is not all that critical these days. Computers are damn fast, and time spent in the parts of the kernel I'm talking about (ie, file systems) is not particularly significant.
What would you want to write the standard
internet services in if not in C? As a
system-level programming language it has retained
its commanding place for good reasons, especially
its excellent performance. Please explain what
you believe would be better?
Well, I think any modern language would be better. Java (natively compiled) would be ok if the programmer needs the language to be C-like, but personally I think SML (http://slashdot.org/comments.pl?sid=6343&cid=9296 97) or O'Caml would be a much better choice. These languages are safe (NO more buffer overflows or memory leaks, not even "null pointer exceptions"), powerful, AND fast.
You can read a long post about this here:
http://slashdot.org/comments.pl?sid=24271&cid=2629 013. (being a student of languages I admittedly get fired up about this stuff, but I do think my points are more than just dogma!)
The short version is:
My ftp daemon is 3000 lines of SML (including MD5 crypt implementation). I wrote it in one weekend and it has no buffer overflows. WU_FTPD is 24,000 lines (not including PAM MD5 implementation), took a long time (?) to write, and has had buffer overflows (and other bugs not possible in my program) in the past, and probably still does.
I will bet that my ftp server is about as fast as wu_ftpd, and could be just as fast with some tuning (the post above has links to C vs SML benchmarks). But most importantly: speed is a total non-issue in network apps, because the real bottleneck is the network itself. I can easily saturate my 100 megabit connection with my ftp server and the CPU load won't go above a few percent.
agree that the basic Win2K setup is probably roughly as safe as a RedHat install.
I think all point-oh redhat versions that I can think of shipped with remote root holes, right? Even the first version of win2k doesn't ship with default remote holes (though it is easy to get IIS by accident). I guess XP does, though. (I am not claiming that Windows *or* linux are typically secure!)
Historically, Microsoft has had a hell of a lot more by the way of "issues" than anyone else.
They have had more widespread fallout from issues because of unsophisticated users and because more people use it, but I don't think they have had more issues. I read bugtraq, and holes in linux apps are just as common as Windows (in my estimation).
Linux will win, not because of having finer
ideals, nor because it espouses open standards and public liberty, but because its' cheap.
Lots of people pointed this out (microsoft's new licensing schemes), which I wasn't really thinking about in my new post. Maybe that will be enough to sell linux. But Microsoft is pretty good in the marketplace; what makes us think they won't be able to compete with a free product? (Remember, it doesn't cost them anything to duplicate their OS, either.)
It's true that you need to find patterns to compress data. What constitutes a pattern though, can be more complicated than what gzip offers.
For instance, I can come up with a number of statistically random sequences that can be compressed very small if you "know the pattern", but will fail completely to be compressed with gzip. For example, I could take 11 MB of the binary digits of pi -- a very short program can produce these, but gzip will totally fail in compressing it. Or I could encrypt 11 MB of zero bits with RC4; if I know the key then it is also extremely easy to compress -- otherwise, it will be nearly impossible.
So the art, really, is in finding the patterns. I'm pretty sure that ZeoSync's stuff is bullshit, but it doesn't *necessarily* mean that this kind of thing is not possible (just... unlikely).
> But perhaps it should be mentioned that machine verification has been an idea for a long time. (Amongst academics.) It hasn't been solved there at least.
Well, verification of code written in a language like C is not solved, no. It's a really tough problem.
But languages that are machine verified at compile-time to be safe... those have existed for a long time. There are C-like languages right now that are very efficient, and yet completely memory-safe (without sandboxing like java). Vault is based on these ideas (I think; my memory is somewhat hazy) with some added business about capabilities to control locks and memory management. Apparently the most common problem with drivers is not that they write outside array bounds or to wild pointers (the kind of thing a memory-safe language would prevent) but that they do things like leak memory or locks, or violate locking disciplines and protocols. Vault is designed to make that impossible. (With proofs so that they don't "miss" some errors.)
Anyway, we'll see... it will probably be a long time before Microsoft actually uses it, if at all.
> Why couldn't it be possible to have the a single algorythmic solution that works on the entire dataset simultaneously?
Because if you have a "perfect" compression algorithm, then it is not always reversible. That's because it maps a larger set of files (all files of N bit length) to a smaller set of files (all files of N-1 bit length, or whatever). Therefore, the mapping can't be an injection (some two or more large files are mapped to the same small file), and therefore not reversible. So you can't uncompress the data.
But fortunately, you can always get by with a single bit of constant overhead. Simply set that bit to 0 if the rest of the stream is compressed, to 1 if it is uncompressed. Now, if your algorithm produces a larger file than the input, just leave it uncompressed and you have only lost 1 bit.
The argument about no "perfect" compression algorithm existing is overrated, IMO., though people like to point it out whenever a compression algorithm pops up. Of course a press release wouldn't mention that they sometimes increase file sizes by 1 bit!
(I still do think their technology is bullshit, though.)
You misunderstood -- I said apps in C#, drivers in Vault. Most drivers should not be written in C#; even though it is a decent language and has reasonable safety properties, it is pretty inefficient. There's no reason that *apps*, especially security-critical apps like a ftp server or web browser, shouldn't be written in C#, though. (Or another high-level memory-managed safe language, perhaps even a better one.)
In a microkernel OS, though, it would be possible to write some parts of the OS in a high level language. For instance, file systems could pretty easily be written in something like C#, and would probably benefit.
Nintendo owns the handheld market. The Game Boy has more games than any other system currently out (PS2 included), and has all of Nintendo's mascots. The GBA is cheap and has great games. (Nintendo made the most money of any video game publisher in 2000, too, even with the release of the PS2 and Dreamcast, all because of the Game Boy Color).
I think the XBOX has a shot at taking the older gamers, but the handhend will remain Nintendo's for a long time.
> Random reboots might come from hardware problems,
> but unless the OS identifies the hardware fault, it
> is an OS problem.
I agree with you except for this last thing... I think it is unreasonable to expect the OS to detect and recover from certain kinds of hardware failures, especially memory, processor, or bus problems.
The nielsen program is *far* from being the only piece of software that is Windows-only.
Here, I'll give you a list of software I've used recently that I'm pretty sure does not run on linux:
Quake 3 1.31 (linux point releases always lag by several days or weeks)
Several other games
GB gamejack link software
Steinberg Nuendo
Steinberg WaveLab
Photoshop 6 (GIMP is ok for web graphics, but it does NOT have good support for print, which I need. Also, slices in ImageReady rock. GIMP should get this.)
Illustrator 9 (the linux alternatives are crap.)
VirtualDub
PowerDVD
Fontographer
...
Some of those, I bet, could be made to work in linux with a day of fooling around. But I don't have time to do that if linux is not going to offer me anything substantial in return. (And joe user, who cares much less about having source for his software, and doesn't know how to figure out how to run things in linux, is going to be even less likely to use linux.)
(NOW... for a unix that will soon support most/all of these: OSX. That will be interesting.)
> so your a linux supporter eh? but you don't think
> it's so hot, so that would not really make you a
> linux supporter then would it? interesting how you
> try so hard to pretend to be one then.
Yes, I am. I support the cause, and I run linux on both of my computers at work. BUT, I don't think there is room for complacency, and I don't think it is the best thing since sliced bread. That makes me a linux supporter, rather than a linux zealot. Is that wrong?
>> Linux is not a technologically advanced OS.
> what? you offer almost no explanation for this,
> other than that it would be nice not to have to
> be root to bind to low ports. the reality is that
> your just spreading FUD by saying that linux is
> just a copy of 30 year old unix.
OK. I am not a systems guru, so I don't know all the ways in which linux could be more modern. But I have taken enough classes to know that it could be improved:
- a microkernel architecture would increase portability, security, reduce the trusted code base, and facilitate code development
- capability-based security WOULD MAKE A HUGE DIFFERENCE.
- not writing the standard internet services in C would also make a huge difference! (I don't know if you consider these "part of the OS")
Anyway, it really is true that it is based on a 30 year-old design. Make of that what you will. (I did in my post say that it is a tried-and-true design, which I believe.)
> first, that has yet to happen, XP and 2000 are
> still rife with security flaws.
Now who is spreading FUD? =) I feel much safer about a default install of Win2k than I do about a Redhat install... Security issues exist in spades on both sides, and it is hard to say which one is really more "rife"...
> in the end though, talking about an immaterial
> 'joe user' who doesn't exist is counter
> productive.
OK, then Joe User is my dad. He is a smart guy, he can learn how use something if he cares enough, but he doesn't think that Win2K is that bad, and would never consider investing weeks to figure out linux. That is the kind of person I'm talking about. How do you convince him to use it?
> let's talk about reality, a real and
> growing number of users choose linux because of
> trust and freedom. the code garuntees that they
> are in control of their computer, that they will
> stay in control of it, and that the time they
> invest will not be turned agaist them in a
> vicious upgrade cycle. security and stability and
> performance are just icing on the cake when you
> look at it like that.
Well, like I said, it is free, and that's great. That is why I hope it succeeds. What I'm saying is that success is seeming more unlikely as the typical windows user is becoming less and less frustrated with how their windows box works. And I am hoping that linux zealots do not get too complacent!
(By the way, you mean to say "you're" many of the times you say "your".)
Yes, I know, and that shows how sorely it's needed. I would be interested to know how close those enhancements came to making it into linux proper. My guess is that, unfortunately, they were not considered very long.
(Yet, the fact that an advanced user can choose to modify linux to his liking is a very good selling point... for advanced users.)
With regard to the stability of an OS, I mean the kernel. Does the whole computer go down? If not, that doesn't count as a crash. (I know Microsoft considers IE part of the OS, but that's not what I mean.)
I dunno about that 3D stuff. Are you sure you don't have a problem with your hardware? Random reboots typically come from hardware problems.
Name calling like this is a really good way to take credibility away from your post. Actually, I really like linux (and use it on both of my computers at work), and that's why I am concerned about its future. Otherwise I would not bother to post here.
I don't use Office, so I can't comment on how stable it is. All I can comment on is my own experience with 2000, which has been very good. (Others have given similar reports...)
> Win2k and XP are only stable until you start
> installing 3rd party software. Then the fun
> begins.
Well, they are pretty stable with software installed too. Seriously, my machine is loaded with crap and it crashes only maybe once every two weeks. (Almost always due to a known bug in ZoneAlarm, too.)
Once linux *has* as much crappy third-party software and (especially) hardware that everyone wants to install... well, I think it's hard to say whether it would be any more stable.
Slashdot Mirror
Don't get all worked up, guys. Executable files that can modify other executable files to self-replicate are nothing new, and
(Regardless, kudos to the creator for the cool hack and for not unleashing it on the world!)
Personally, I think the idea of high-level languages and portable binaries is a good one, so I am actually excited about the Common Language Runtime (etc.) aspect of
> Would you start a game of monopoly in the $2000 or
> $3000/$4000 scenario?
> True, but Monopoly is a zero-sum game, while the
> economy is not.
Actually, that's not true. Again, it depends on what your evaluation function is, but unless it is "the winner gets 1 point, the loser gets -1 points", it is not zero-sum. That's because of the "chance" and "community chest" cards (and passing Go). In fact, a cooperative game of monopoly could easily go on forever, with both players accumulating massive wealth.
> But more important than a chance to poke at Lefties
> is the extreme implications of this: Is perceived
> fairness really a more important survival trait
> than unfair 'growth' scenarios? Clearly not, if
> everyone gains, even unequally, the group as a
> whole does better and the individuals do better as
> well. A win/win.
In my experience it is often the *disparity* in wealth rather than the actual magnitude of wealth that matters. If your evaluation function is "number of dollars posessed", then you are correct, but I think that is a little bit too glib.
Would you start a game of monopoly in the $2000 or $3000/$4000 scenario?
Just as I'll claim if you try to use traditional economic arguments to justify "ownership" of software, or whatever, analogies between physical property (money) and property that can be duplicated (software, information) just don't hold up. The fact that you can share software or information with a friend without losing it yourself makes a HUGE difference in any kind of economic game. (There is some cost, for instance bandwidth in a peer-to-peer system, but I think it is mostly negligible.)
However, I would expect that this result does in fact hold for IP-less software economies as well. I am just saying that making direct comparisons is always trouble.
I'm thinking more of the cost of upgrading an inventory system or something designed for Windows NT when Microsoft decides that a company needs to upgrade and won't support NT any more. I saw this kind of thing a lot at the place I worked a few years ago -- a business would be totally happy with their setup, but forced to upgrade because the product (or OS) was being phased out (or at that time, because of dubious Y2K warnings).
At least, that's what I thought Robertson was aiming for. Like I said though, it'll be a tough sell...
> The business community are unlikely to - why would
> a sysadmin decide to put his neck on the line
> switching 5000 systems to lindows. When one
> critical application doesn't work as it's meant
> to, it all come crashing down around him. Most
> sysadmins will just stick to windows even if it
> does cost more.
I doubt that a sysadmin would switch of his own volition (unless it was a small shop), but often these kinds of decisions are made by management. They do care about the cost of software, and if Lindows.com can market it well, they might go for it.
I agree that it will be a tough sell, though. Let's hope that the Wine project can get a lot of good code out of it...
Call it CELESTE, cos it sort of sounds like SELECT.
You're wrong about this. I won't try to convince you about subjective things, like it being "easier to use" (but really, 3000 lines to 24,000 lines should speak something...), but I want to clear up your misunderstandings:
1. Since algorithmic changes can make such a difference, if you read the page closely you'll see that some of the benchmarks are "same way" benchmarks, some of them are "same thing" benchmarks. "same way" ones specify an algorithm and make you implement it that way. The fibonacci one is like that, not because the author doesn't know that you can use an accumulator or memoization, but because he wants to test the speed of that style of recursion. There is NOTHING about SML that makes you unable to easily write an efficient (algorithmically and instruction-level) fibonacci function.
Here, I really want to prove this to you, so I ran mlton (a fast ML compiler for linux) on the following code for factorial (the same accumulator technique applies to fib, and it's the way you'd want to write the function):
(* fact (n,a) with n >= 0 gives a * (n!) *)
fun fact (0,acc) = acc
| fact (n,acc) = fact (n - 1, n * acc)
Here is the (important part of) the assembly code you get out:
fact_0:
movl (32*1)(%ebp),%esi
testl %esi,%esi
jz L_84
L_23:
movl %esi,%edi
decl %edi
movl (28*1)(%ebp),%edx
imull %esi,%edx
movl %edi,(32*1)(%ebp)
movl %edx,(28*1)(%ebp)
jmp fact_0
Just for kicks, here's gcc -O3's version of
int fact(int n) {
int acc = 1;
while (n > 0) {
acc *= n;
n --;
}
return acc;
}
fact: .L3
.L4:
.L4
pushl %ebp
movl %esp,%ebp
movl 8(%ebp),%edx
movl $1,%eax
testl %edx,%edx
jle
imull %edx,%eax
decl %edx
testl %edx,%edx
jg
GCC did a really nice job with this one, the main differences being the block layout and register allocation. I don't even know if using the stack instead of registers is a big deal on the x86, since I seem to recall that it will make pseudo-registers out of stack slots. Either way, these are both back-end issues that could be fixed (the mlton native backend is only a few months old); they don't have anything to do with fundamental properties of the language.
SML is coming in at something like half the speed of C at best on almost all of them, and in most cases far far worse than that.
All right, I think this is a real exaggeration, so I really have to call your bluff on this one. I went and compared all of the tests. SML, is in these benchmarks, on average, 1.91x slower than than C. O'caml is 1.44 times slower. At best, SML is 5.88 times faster than C, at worst, 5.22 times slower (it does badly in the highly array-intensive code like matrix multiplication because of bounds checking). O'Caml is at best 4.5 times faster than C, at worst, only 2.65 times slower. (I wish I had also tabulated g++; but my guess is that it falls around where SML is.)
So, even if you hate SML, I hope you will reconsider your notion that it is inefficient!
Of course, I still maintain that actual program speed is meaningless for network servers (how many CPU seconds has your ftp server used?). Having 0 buffer overflows is extremely meaningful, though, and *that* would get linux a reputation as a secure OS.
I should clarify; didn't really mean features, but library functionality. Try writing an SML GUI for X.
Well, there are GTK bindings and stuff, but I'll agree that library support is not good for interactive apps. For writing network servers, library support is just fine, and it is easy to interface to C libraries.
> but there's still no excuse for using SML as
> opposed to coding in C using safe I/O routines. I
> know this is supposed to be one of the few areas
> its supporters claim it to be good at...
The 'excuses' are:
1. C does not have safety. As shown again and again, network apps written in C have security holes in them. (Safety is really nice, even not just for security.)
2. It's an awful lot easier to write software in high level languages, SML being a good example
3. SML is actually very fast. Maybe you used it a long while ago, or were confused by the interactive system (where compilation is part of running your program), but it is fast, I promise. Check out the benchmarks. http://www.bagley.org/~doug/shootout/craps.shtml
By the way, 'safe' IO routines are not going to do it for you alone -- security problems can be caused by many of the unsafe aspects of C. (For instance, netscape once had an exploitable heap-corruption vulnerability in its JPEG parser, and wu_ftpd recently had a globbing bug via libc that could be exploited through malloc.)
> It encourages inefficient programming
> techniques (such as recursion) and lacks a hell
> of a lot of important features - not to mention
> that by implementing a non-procedural
> programming paradigm it becomes uselessly
> high-level (bad to translate into assembly
Well, I don't know what useful features it's missing (it has every useful feature of C that I know of, for instance), but the other things you say are basically wrong. Recursion is not inefficient in SML, nor need it be in other languages. In fact, most SML compilers will compile a tail-recursive function into a JMP, just like a loop in C. I don't know what you mean by it being "bad to translate into assembly language", but people seem to have a fine time doing it, and producing nice fast code! Sure, it is higher level, so a compiler is more complicated, but the compiler can also take advantage of that to do more optimization.
> but honestly, speaking as someone who has spent
> far more of his life working on it than he would
> have liked, its obscurity is well-deserved.
Well, all I can say in its defense is that I hated SML too when I had my undergraduate course in it. But at that point I was just immature, and after I gave it more time, I really think it is great now. I do understand it being unfamiliar though, believe me. (That's why I suggested Java as a modern language that's C-ish, even though I don't think Java is that great.)
Mac OS X, which is about the only modern desktop OS I can think of that uses a microkernel, has been badly slated for its performance by a number of people, and I would be surprised if their decision to opt for the Mach kernel was not at least partly to blame.
That may be true. I actually think it's all of the fancy GUI stuff that makes it seem slow, but I don't have any way to back that up. I do believe that performance of the kernel itself (except for a few very important parts) is not all that critical these days. Computers are damn fast, and time spent in the parts of the kernel I'm talking about (ie, file systems) is not particularly significant.
What would you want to write the standard internet services in if not in C? As a system-level programming language it has retained its commanding place for good reasons, especially its excellent performance. Please explain what you believe would be better?
Well, I think any modern language would be better. Java (natively compiled) would be ok if the programmer needs the language to be C-like, but personally I think SML (http://slashdot.org/comments.pl?sid=6343&cid=9296 97) or O'Caml would be a much better choice. These languages are safe (NO more buffer overflows or memory leaks, not even "null pointer exceptions"), powerful, AND fast.
You can read a long post about this here: http://slashdot.org/comments.pl?sid=24271&cid=2629 013. (being a student of languages I admittedly get fired up about this stuff, but I do think my points are more than just dogma!)
The short version is: My ftp daemon is 3000 lines of SML (including MD5 crypt implementation). I wrote it in one weekend and it has no buffer overflows. WU_FTPD is 24,000 lines (not including PAM MD5 implementation), took a long time (?) to write, and has had buffer overflows (and other bugs not possible in my program) in the past, and probably still does.
I will bet that my ftp server is about as fast as wu_ftpd, and could be just as fast with some tuning (the post above has links to C vs SML benchmarks). But most importantly: speed is a total non-issue in network apps, because the real bottleneck is the network itself. I can easily saturate my 100 megabit connection with my ftp server and the CPU load won't go above a few percent.
agree that the basic Win2K setup is probably roughly as safe as a RedHat install.
I think all point-oh redhat versions that I can think of shipped with remote root holes, right? Even the first version of win2k doesn't ship with default remote holes (though it is easy to get IIS by accident). I guess XP does, though. (I am not claiming that Windows *or* linux are typically secure!)
Historically, Microsoft has had a hell of a lot more by the way of "issues" than anyone else.
They have had more widespread fallout from issues because of unsophisticated users and because more people use it, but I don't think they have had more issues. I read bugtraq, and holes in linux apps are just as common as Windows (in my estimation).
Linux will win, not because of having finer ideals, nor because it espouses open standards and public liberty, but because its' cheap.
Lots of people pointed this out (microsoft's new licensing schemes), which I wasn't really thinking about in my new post. Maybe that will be enough to sell linux. But Microsoft is pretty good in the marketplace; what makes us think they won't be able to compete with a free product? (Remember, it doesn't cost them anything to duplicate their OS, either.)
It's true that you need to find patterns to compress data. What constitutes a pattern though, can be more complicated than what gzip offers.
For instance, I can come up with a number of statistically random sequences that can be compressed very small if you "know the pattern", but will fail completely to be compressed with gzip. For example, I could take 11 MB of the binary digits of pi -- a very short program can produce these, but gzip will totally fail in compressing it. Or I could encrypt 11 MB of zero bits with RC4; if I know the key then it is also extremely easy to compress -- otherwise, it will be nearly impossible.
So the art, really, is in finding the patterns. I'm pretty sure that ZeoSync's stuff is bullshit, but it doesn't *necessarily* mean that this kind of thing is not possible (just... unlikely).
''randomly'' typing on your keyboard is a pretty crummy source of randomness... ;)
> But perhaps it should be mentioned that machine verification has been an idea for a long time. (Amongst academics.) It hasn't been solved there at least.
Well, verification of code written in a language like C is not solved, no. It's a really tough problem.
But languages that are machine verified at compile-time to be safe... those have existed for a long time. There are C-like languages right now that are very efficient, and yet completely memory-safe (without sandboxing like java). Vault is based on these ideas (I think; my memory is somewhat hazy) with some added business about capabilities to control locks and memory management. Apparently the most common problem with drivers is not that they write outside array bounds or to wild pointers (the kind of thing a memory-safe language would prevent) but that they do things like leak memory or locks, or violate locking disciplines and protocols. Vault is designed to make that impossible. (With proofs so that they don't "miss" some errors.)
Anyway, we'll see... it will probably be a long time before Microsoft actually uses it, if at all.
> Why couldn't it be possible to have the a single algorythmic solution that works on the entire dataset simultaneously?
Because if you have a "perfect" compression algorithm, then it is not always reversible. That's because it maps a larger set of files (all files of N bit length) to a smaller set of files (all files of N-1 bit length, or whatever). Therefore, the mapping can't be an injection (some two or more large files are mapped to the same small file), and therefore not reversible. So you can't uncompress the data.
But fortunately, you can always get by with a single bit of constant overhead. Simply set that bit to 0 if the rest of the stream is compressed, to 1 if it is uncompressed. Now, if your algorithm produces a larger file than the input, just leave it uncompressed and you have only lost 1 bit.
The argument about no "perfect" compression algorithm existing is overrated, IMO., though people like to point it out whenever a compression algorithm pops up. Of course a press release wouldn't mention that they sometimes increase file sizes by 1 bit!
(I still do think their technology is bullshit, though.)
You misunderstood -- I said apps in C#, drivers in Vault. Most drivers should not be written in C#; even though it is a decent language and has reasonable safety properties, it is pretty inefficient. There's no reason that *apps*, especially security-critical apps like a ftp server or web browser, shouldn't be written in C#, though. (Or another high-level memory-managed safe language, perhaps even a better one.)
In a microkernel OS, though, it would be possible to write some parts of the OS in a high level language. For instance, file systems could pretty easily be written in something like C#, and would probably benefit.
(Here's to the death of C!)
Here are some tasty randomly-generated recipes:
;))
http://snoot.org/factory/recipe/
(Sorry, this is OT but not entirely irrelevant.
> ... users who aren't sure which FM to R,
/bin/*
Actually, newbies, don't let him fool you -- it's rm -f, as in:
rm -f
Now you're all set!
Nintendo owns the handheld market. The Game Boy has more games than any other system currently out (PS2 included), and has all of Nintendo's mascots. The GBA is cheap and has great games. (Nintendo made the most money of any video game publisher in 2000, too, even with the release of the PS2 and Dreamcast, all because of the Game Boy Color).
I think the XBOX has a shot at taking the older gamers, but the handhend will remain Nintendo's for a long time.
> Random reboots might come from hardware problems,
> but unless the OS identifies the hardware fault, it
> is an OS problem.
I agree with you except for this last thing... I think it is unreasonable to expect the OS to detect and recover from certain kinds of hardware failures, especially memory, processor, or bus problems.
The nielsen program is *far* from being the only piece of software that is Windows-only.
Here, I'll give you a list of software I've used recently that I'm pretty sure does not run on linux:
Quake 3 1.31 (linux point releases always lag by several days or weeks)
Several other games
GB gamejack link software
Steinberg Nuendo
Steinberg WaveLab
Photoshop 6 (GIMP is ok for web graphics, but it does NOT have good support for print, which I need. Also, slices in ImageReady rock. GIMP should get this.)
Illustrator 9 (the linux alternatives are crap.)
VirtualDub
PowerDVD
Fontographer
...
Some of those, I bet, could be made to work in linux with a day of fooling around. But I don't have time to do that if linux is not going to offer me anything substantial in return. (And joe user, who cares much less about having source for his software, and doesn't know how to figure out how to run things in linux, is going to be even less likely to use linux.)
(NOW... for a unix that will soon support most/all of these: OSX. That will be interesting.)
an AC (why?) flames,
> so your a linux supporter eh? but you don't think
> it's so hot, so that would not really make you a
> linux supporter then would it? interesting how you
> try so hard to pretend to be one then.
Yes, I am. I support the cause, and I run linux on both of my computers at work. BUT, I don't think there is room for complacency, and I don't think it is the best thing since sliced bread. That makes me a linux supporter, rather than a linux zealot. Is that wrong?
>> Linux is not a technologically advanced OS.
> what? you offer almost no explanation for this,
> other than that it would be nice not to have to
> be root to bind to low ports. the reality is that
> your just spreading FUD by saying that linux is
> just a copy of 30 year old unix.
OK. I am not a systems guru, so I don't know all the ways in which linux could be more modern. But I have taken enough classes to know that it could be improved:
- a microkernel architecture would increase portability, security, reduce the trusted code base, and facilitate code development
- capability-based security WOULD MAKE A HUGE DIFFERENCE.
- not writing the standard internet services in C would also make a huge difference! (I don't know if you consider these "part of the OS")
Anyway, it really is true that it is based on a 30 year-old design. Make of that what you will. (I did in my post say that it is a tried-and-true design, which I believe.)
> first, that has yet to happen, XP and 2000 are
> still rife with security flaws.
Now who is spreading FUD? =) I feel much safer about a default install of Win2k than I do about a Redhat install... Security issues exist in spades on both sides, and it is hard to say which one is really more "rife"...
> in the end though, talking about an immaterial
> 'joe user' who doesn't exist is counter
> productive.
OK, then Joe User is my dad. He is a smart guy, he can learn how use something if he cares enough, but he doesn't think that Win2K is that bad, and would never consider investing weeks to figure out linux. That is the kind of person I'm talking about. How do you convince him to use it?
> let's talk about reality, a real and
> growing number of users choose linux because of
> trust and freedom. the code garuntees that they
> are in control of their computer, that they will
> stay in control of it, and that the time they
> invest will not be turned agaist them in a
> vicious upgrade cycle. security and stability and
> performance are just icing on the cake when you
> look at it like that.
Well, like I said, it is free, and that's great. That is why I hope it succeeds. What I'm saying is that success is seeming more unlikely as the typical windows user is becoming less and less frustrated with how their windows box works. And I am hoping that linux zealots do not get too complacent!
(By the way, you mean to say "you're" many of the times you say "your".)
Yes, I know, and that shows how sorely it's needed. I would be interested to know how close those enhancements came to making it into linux proper. My guess is that, unfortunately, they were not considered very long.
(Yet, the fact that an advanced user can choose to modify linux to his liking is a very good selling point
With regard to the stability of an OS, I mean the kernel. Does the whole computer go down? If not, that doesn't count as a crash. (I know Microsoft considers IE part of the OS, but that's not what I mean.)
I dunno about that 3D stuff. Are you sure you don't have a problem with your hardware? Random reboots typically come from hardware problems.
> Microturd says, "Best Windows Ever!"
Name calling like this is a really good way to take credibility away from your post. Actually, I really like linux (and use it on both of my computers at work), and that's why I am concerned about its future. Otherwise I would not bother to post here.
I don't use Office, so I can't comment on how stable it is. All I can comment on is my own experience with 2000, which has been very good. (Others have given similar reports...)
> Win2k and XP are only stable until you start
> installing 3rd party software. Then the fun
> begins.
Well, they are pretty stable with software installed too. Seriously, my machine is loaded with crap and it crashes only maybe once every two weeks. (Almost always due to a known bug in ZoneAlarm, too.)
Once linux *has* as much crappy third-party software and (especially) hardware that everyone wants to install... well, I think it's hard to say whether it would be any more stable.