I'm not saying all operating systems are the same. I'm merely saying that the differences between those specific operating systems (BeOS, OSX, Windows, Linux, UNIX) largely comes do marketing, quality, and business issues. In terms of functionality, limitations, and technology, they are pretty similar to one another as far as I'm concerned.
Prithee sir, I guess you are missing Scott's point here. BeOS's architecture has (had?) strong departures from Windows's or OSX's.
And my point is that Scot is confused if he uses Windows, OSX, UNIX, and Linux to represent the entirety of past thought on OS design. If BeOS has a feature that isn't in those systems, it doesn't mean that the feature is new, it usually means that the other systems left it out for one reason or another.
Think about the virtual database at the core of BFS
Well, that's a particularly silly example of a departure since NT has had the same facilities for a number of years. And they have been in many operating systems prior to NT. The fact that they are not widely used suggests that they are less useful than they appear on the surface.
The debates over whether Linux, OSX, Windows, or BeOS are technically better are roughly like the debates over whether Ford or General Motors make better cars. There may be some differences in technology, style, and quality, and there may be some preferences, but they are basically the same mode of transportation. There is no technology in any of them that is fundamentally ahead of the technology of any of the others, marketing departments notwithstanding. Most of the differences are a matter of taste, not some deep insight that one group had and another one lacked (in particular, all the features Hacker likes in BeOS had been considered by other OS designers--and rejected).
The real distinguishing factors are not the technology, they are the business positions. Windows comes from a wealthy, ruthless monopolist that knows how to generate a steady revenue stream by controlling APIs and formats. OSX comes from an upscale vendor with a valuable brand name and stylish design. Linux comes from a large group of volunteer developers and has a DYI flavor.
And BeOS? Well, BeOS came from a small company that failed to sell to its one major potential client and somewhat predictably went out of business. That's the reason why most developers wouldn't touch it with a ten foot pole, no matter what its technical merits may have been.
Here is a link to the lab's home page. The project is described briefly here. It would be nice if web-based included those links. It would also be nice if people in the biological sciences followed CS and put their publications on-line.
Re:additional corrections
on
Parrot Updates
·
· Score: 2
The JVM is a virtual machine specification. It's as much an "interpreter" as a specification of the Pentium instruction set is an interpreter, or as a photograph of a giraffe is a giraffe. The specification is stack based, but high performance implementations of it usually are not (they use the stack in the same way as any register-based instruction set, and as Perl6 does--to store activation frames and local variables). And, having implemented the transformation, I assure you that it is trivial--it's a couple of pages of code. What is hard is to assign the large number of registers you get that way to the few number of registers some machine has. But, guess what, that's the same problem you face with a register-based virtual machine, since you don't know ahead of time how many, or what kind of, registers any particular implementation can most efficiently support.
A different way of looking at what the JVM and the CLR do is that they are a binary postfix representation of the Java parse tree. It doesn't make register allocation any harder or easier, it simply draws the line between source->byte-code->execution at a slightly different point. And it makes sense to draw the line where the JVM (and the CLR and the Smalltalk VM and lots of other virtual machines) does because register allocation is target machine specific.
Arguing theoretically against the architecture of some of the most efficient and successful virtual machine based systems is futile. The proof is in the pudding. Current Perl interpreter performance is noticeably worse than many other interpreters (even if some Perl primitives like regular expressions are quite fast). Let's hope that will improve in Perl6 implemetations. If you can do that with a register based VM, great.
The Java VM is not a "stack based interpreter". First of all, it's not an interpreter. More importantly, the Java byte codes are restricted in such a way that they are trivially converted into a register machine. In fact, the "restricted stack" approach that both JVM and CLR take has all the efficiency advantages of register machines and all the compactness and simplicity of stack machines. Perl6's method is likely much inferior.
That's useful to know. Why do you need the MOTU if you have the Apogee? The latter seems to be doing both recording and playback. Also, can you get the input from the MOTU through a FireWire card into Linux? Are there drivers?
Re:microkernels may be the way out
on
Hurd: H2 CD Images
·
· Score: 5, Insightful
A microkernel-based OS would be just as big.
Of course it would. But the different parts of it (drivers, file systems, personalities, distributed shared memory, clustering, video support, VM strategies, etc.) could be developed and tested by different developers, independently. With the Linux architecture, almost everything goes through the bottleneck of the Linux kernel developers, and it just isn't working in practice: important functionality takes years to make it into the kernel. It's not for lack of effort or dedication, it's the architecture and lack of modularity.
The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary.
Of course, compiling is "complicated". It a process that involves many steps and is completely alien to many users. It also takes forever. And minor configuration problems result in complete failure. And if the module you want isn't part of the kernel distribution, things only get worse.
With a microkernel, module installation could be as easy as installing a new command line program. You can still make configuration mistakes, but a lot of the time and effort can be eliminated. And with a really good microkernel architecture, you can also automate the process much more than it currently is.
Experience has shown that a moduler monolithic kernel seems to be working quite well.
It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.
microkernels may be the way out
on
Hurd: H2 CD Images
·
· Score: 5, Insightful
I think this may be the way out for the current problems with the Linux kernel. The 2.4.17 Linux kernel distribution is almost 30Mbytes of sources, gzipped. Most drivers, installable file systems, and other kernel functionality, are either in the kernel source or need to be installed from sources. Getting the right ACPI or APM options requires endless recompiling and rebooting. A bug in any one kernel module will usually take down the whole system. None of the major Linux distributions has placed reconfiguration of the kernel within reach of the average user, and even for the experienced user it's kind of a pain. Imagine where Linux would be today if you needed to recompile the entire command line toolkit or all of KDE every time you install a new version.
Microkernels attempt to give you a much more "UNIX-like" way of making a kernel: a lot of independent little "servers" that talk to each other and are somewhat isolated from each other. A bug in one kernel module will often not crash the whole system, and there is much less coupling between kernel components. Microkernels are not the most efficient way of achieving that kind of modularity, since the memory protection mechanisms they use are more costly than relying on compiler/language support together with dynamic loading, but given that people are going to continue to write lots of C code for the kernel, a microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
Well, it's good to see that both the Hurd and the Darwin projects are coming along. I'll certainly give this a try. Its hard for any new kernel architecture to replace something as mature, functional, and widely-used as Linux. But if something like the Hurd turns out to be significantly easier to extend and hack, it may well catch up quickly. Another path to acceptance is that people find that, despite having fewer drivers and less functionality, the functionality that something like the Hurd offers may be easier to configure and deliver to end users in prepackaged form (i.e., without "make menuconfig" and lots of obscure decisions).
I don't understand why the record labels are expending so much effort and political capital on this. I mean, you can rip any CD by just connecting to the analog audio output. Sure, it's 1x, but you can do it while you listen to the CD or automate it with an audio jukebox. Given that MP3 is a bit worse than CD anyway, any theoretical loss in quality doesn't matter (and a bit of analog degradation might do the CD recording some good anyway). And once it's in MP3 format, you can send it to the whole world.
Not even watermarking is going to see them out of this. Watermarks can be removed anyway, and even if they succeed in a lunatic scheme to require that every computer audio board have some kind of watermark detection circuit, A/D and D/A converters that are fast enough and good enough are cheap, widely available, and easily hooked up to a PC.
Are the record labels just clueless or is there some other diabolical plan in the wings?
Cyclone probably is too slow and too complex, and it seems to have a non-trivial runtime. Ada might be an OK choice, but it is also a very big language. Traditional language choices that have worked fine for writing kernels include various Pascal and Modula variants.
Other systems programming languages (e.g., Ada or Modula) allow you to access any memory location as any type and to convert between arbitrary types, just like C. The difference is that when you do so, you have to say so explicitly. In C, something like "p[i]" might be a completely safe and portable high-level array subscripting operation, or it might be an unportable and dangerous way of accessing a memory-mapped I/O location. The fact that you can't tell is a very serious and fundamental flaw of the language.
C++ is a little better than C in that it at least lets you define a reasonably safe framework, but the Linux kernel developers have been strenuously opposed even to C++.
Prior to the rise of UNIX and Windows, most kernels were written in other languages, so it's not hard to do.
BTW, while using a safe language does not require using garbage collection, garbage collection has many benefits. Here is the experience with GCC 3.0 (from http://www.codesourcery.com/publications.html):
The memory management scheme used by the com- piler itself was radically altered for the GCC 3.0 release. Memory allocated by the compiler is now garbage collected; previous releases used a complex system of memory pools. This change greatly re- duced the number of memory-allocation bugs in the compiler, and simpli ed the implementation of new features. Use of garbage collection, and other associated im- provements associated with memory management, have dramatically reduced the memory footprint of the compiler in some cases. There have been im- provements as great as 60% (from approximate 300 MB to approximately 100MB) when compiling some C++ programs. vantage of these features.
C-style manual storage management is not only error prone, unsafe, and cumbersome, it often is also inefficient.
Despite all the people that attack C and C , there really isn't any substitute for their performance.
There are many systems programming languages that are as fast as C/C++ and have similar memory footprints. Examples are Ada, Modula, and various Pascal derivatives. These languages allow you to do everything you can do in C/C++, they simply are safe by default.
What can be done in any high level language that cannot also be done in C or C++? Answer: nothing.
Why do we need safety belts and airbags? Can't people just drive carefully?
Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications.
Yes, indeed, we know exactly what kind of code real programmers produce in C and C++: systems full of security holes and buffer overruns. The fact that these bugs keep occurring even though programmers know better is exactly what demonstrates that C/C++ are not up to the task.
Purely as an engineering tradeoff, I'm not sure that this helps very much. While this may slow down a determined attacker, this kind of approach tends to fall like a series of domnios: the first one gets compromised giving the attacker a few more capabilities, then the next one, etc. The Linux kernel was simply not designed with ensuring this kind of isolation.
As a practical matter, it may help a lot because it makes the machine different from other Linux machines. It may be not too hard conceptually to work out how to break through this kind of security, it will likely protect systems from common exploits of common bugs.
However, in the long term, the only solution I see to security problems is to build on foundations that have support for guarding against common bugs and analyzing security-related program properties. That means, among other things, using languages with built-in default checks for buffer overruns and using languages with type systems that can be used to verify that data doesn't get where it isn't supposed to get (Perl's notion of "tainted" is a simple runtime example; similar static type checking is also possible in some cases). Decades of UNIX, Windows, and Linux software development and bug tracking have shown that without such support, even skilled programmers simply cannot write software containing very serious security problems in actual releases. In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.
this is also a problem with bank cards
on
Gift Card Hacking
·
· Score: 2
Some banks issue ATM and credit cards with sequential or nearly sequential numbers, and they may not require activation for some of the cards. Someone getting a card can make a guess at the next numbers in the sequence and start charging. This is apparently what happened to a card I got when I opened a new account: before I had even opened the envelope, several thousand dollars were gone. Sometimes, the stupidity of some of those supposedly security-conscious money institutions is just amazing.
With Windows compatibility libraries (either open source, like Willows, or commercial), porting applications from Windows to UNIX is not a big deal. That's particularly true for Microsoft, which has lots of resources and has all the Windows source code should they need it. The cost would probably be a fraction of the cost of creating an OSX port.
I suspect Microsoft probably just doesn't see any value in this. Right now, they likely perceive the market as small. And if the market ever got big, that would just mean that their desktop monopoly was threatened. What possible reason would they have to port?
And, frankly, do we really want it? MS Office on Linux would completely wipe out all the other efforts. Sure, Linux would get more commercial users, but they would all be just as tied to Microsoft as they are now. I'd rather see less adoption of Linux and more open source efforts.
They are using blue not because of sensitivity, but because, as they say,
A principle disadvantage of the triad is the reliance of the blue pixel to carry high-resolution luminance information, a task that it cannot fulfill due to limitations in the human vision system.
Rearranging the color pixels for color stealing is a reasonable idea, and making blue a little bigger is a nice tweak. Is it worth it? That's difficult to say. Subpixel rendering using color stealing on current LCDs actually does roughly put the extra resolution where you want it for high resolution text--vertical lines are the problem in small text, no horizontal lines.
I'd recommend learning mutt as the e-mail client, one of the screen oriented news readers (if you care about news), vim as a text editor, and links or lynx as a web browser. The "screen" program can be used to multiplex. If you want something more coherent, you can get most of that functionality within Emacs or Xemacs. All that stuff has some mouse support, but it also works great over dial-up and doesn't use a lot of resources by modern standards.
If you want some graphics and multiple windows, X11 is actually not that heavy-weight, although Gnome and KDE are. Consider running plain X11 with "twm", "fvwm", or Oroborus. Of those, "twm" is ubiquitous, while oroborus is a little more modern. For minimal graphical web browsing, consider the "dillo" web browser, although it won't work on complex sites. You could also download Opera, although it's commercial.
I think that's the wrong direction. Standards and authorities are what got us to this point. Rather than having a kernel into which anybody can plug anything easily, we have, on the one hand, a kernel that cannot easily be extended "from the outside", and, on the other hand, a small group of people that exercise tight control over what goes into the kernel.
Standardization and centralization create bottlenecks. What we need is a more flexible way of putting together lots of different drivers and kernel modules to make a kernel, something that doesn't involve a top-level makefile and a big include tree and lots of version numbers and symbol addresses. Think of how any command line program fits into the shell environment and can potentially be used with any other. That's the kind of composability we need for the kernel. It's what Mach tried for (whether it achieved it is another matter).
Physical security--how quaint. Even if you greatly overengineer it, a widely distributed network of nodes using cryptographic techniques is likely to be much cheaper and no less secure. And it's also likely to be more resilient.
I think the biggest thing that is hurting Linux is the fact that ease of hardware support and upgrades are still major issues.
I agree that that's a big problem. At the root is the kernel architecture. What we need is a flexible component architecture that allows people to distribute drivers and other kernel components without being tied tightly to exact version of the kernel. If the Linux kernel developers are unable to do this, maybe the Linux kernel needs to go--unlike GUIs, there are many open source alternatives available.
Doesn't terrify me. That's the bank's problem. I have paper records. And banks are not ordinarily affected by worms anyway.
Besides, given that the majority of Americans have no savings or are deeply in debt, maybe they aren't so terrified after all by a major screwup in bank records.
Slashdot Mirror
I'm not saying all operating systems are the same. I'm merely saying that the differences between those specific operating systems (BeOS, OSX, Windows, Linux, UNIX) largely comes do marketing, quality, and business issues. In terms of functionality, limitations, and technology, they are pretty similar to one another as far as I'm concerned.
And my point is that Scot is confused if he uses Windows, OSX, UNIX, and Linux to represent the entirety of past thought on OS design. If BeOS has a feature that isn't in those systems, it doesn't mean that the feature is new, it usually means that the other systems left it out for one reason or another.
Think about the virtual database at the core of BFS
Well, that's a particularly silly example of a departure since NT has had the same facilities for a number of years. And they have been in many operating systems prior to NT. The fact that they are not widely used suggests that they are less useful than they appear on the surface.
The real distinguishing factors are not the technology, they are the business positions. Windows comes from a wealthy, ruthless monopolist that knows how to generate a steady revenue stream by controlling APIs and formats. OSX comes from an upscale vendor with a valuable brand name and stylish design. Linux comes from a large group of volunteer developers and has a DYI flavor.
And BeOS? Well, BeOS came from a small company that failed to sell to its one major potential client and somewhat predictably went out of business. That's the reason why most developers wouldn't touch it with a ten foot pole, no matter what its technical merits may have been.
Here is a link to the lab's home page. The project is described briefly here. It would be nice if web-based included those links. It would also be nice if people in the biological sciences followed CS and put their publications on-line.
A different way of looking at what the JVM and the CLR do is that they are a binary postfix representation of the Java parse tree. It doesn't make register allocation any harder or easier, it simply draws the line between source->byte-code->execution at a slightly different point. And it makes sense to draw the line where the JVM (and the CLR and the Smalltalk VM and lots of other virtual machines) does because register allocation is target machine specific.
Arguing theoretically against the architecture of some of the most efficient and successful virtual machine based systems is futile. The proof is in the pudding. Current Perl interpreter performance is noticeably worse than many other interpreters (even if some Perl primitives like regular expressions are quite fast). Let's hope that will improve in Perl6 implemetations. If you can do that with a register based VM, great.
The Java VM is not a "stack based interpreter". First of all, it's not an interpreter. More importantly, the Java byte codes are restricted in such a way that they are trivially converted into a register machine. In fact, the "restricted stack" approach that both JVM and CLR take has all the efficiency advantages of register machines and all the compactness and simplicity of stack machines. Perl6's method is likely much inferior.
That's useful to know. Why do you need the MOTU if you have the Apogee? The latter seems to be doing both recording and playback. Also, can you get the input from the MOTU through a FireWire card into Linux? Are there drivers?
Of course it would. But the different parts of it (drivers, file systems, personalities, distributed shared memory, clustering, video support, VM strategies, etc.) could be developed and tested by different developers, independently. With the Linux architecture, almost everything goes through the bottleneck of the Linux kernel developers, and it just isn't working in practice: important functionality takes years to make it into the kernel. It's not for lack of effort or dedication, it's the architecture and lack of modularity.
The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary.
Of course, compiling is "complicated". It a process that involves many steps and is completely alien to many users. It also takes forever. And minor configuration problems result in complete failure. And if the module you want isn't part of the kernel distribution, things only get worse.
With a microkernel, module installation could be as easy as installing a new command line program. You can still make configuration mistakes, but a lot of the time and effort can be eliminated. And with a really good microkernel architecture, you can also automate the process much more than it currently is.
Experience has shown that a moduler monolithic kernel seems to be working quite well.
It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.
Microkernels attempt to give you a much more "UNIX-like" way of making a kernel: a lot of independent little "servers" that talk to each other and are somewhat isolated from each other. A bug in one kernel module will often not crash the whole system, and there is much less coupling between kernel components. Microkernels are not the most efficient way of achieving that kind of modularity, since the memory protection mechanisms they use are more costly than relying on compiler/language support together with dynamic loading, but given that people are going to continue to write lots of C code for the kernel, a microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
Well, it's good to see that both the Hurd and the Darwin projects are coming along. I'll certainly give this a try. Its hard for any new kernel architecture to replace something as mature, functional, and widely-used as Linux. But if something like the Hurd turns out to be significantly easier to extend and hack, it may well catch up quickly. Another path to acceptance is that people find that, despite having fewer drivers and less functionality, the functionality that something like the Hurd offers may be easier to configure and deliver to end users in prepackaged form (i.e., without "make menuconfig" and lots of obscure decisions).
Not even watermarking is going to see them out of this. Watermarks can be removed anyway, and even if they succeed in a lunatic scheme to require that every computer audio board have some kind of watermark detection circuit, A/D and D/A converters that are fast enough and good enough are cheap, widely available, and easily hooked up to a PC.
Are the record labels just clueless or is there some other diabolical plan in the wings?
Cyclone probably is too slow and too complex, and it seems to have a non-trivial runtime. Ada might be an OK choice, but it is also a very big language. Traditional language choices that have worked fine for writing kernels include various Pascal and Modula variants.
C++ is a little better than C in that it at least lets you define a reasonably safe framework, but the Linux kernel developers have been strenuously opposed even to C++.
Prior to the rise of UNIX and Windows, most kernels were written in other languages, so it's not hard to do.
There are many systems programming languages that are as fast as C/C++ and have similar memory footprints. Examples are Ada, Modula, and various Pascal derivatives. These languages allow you to do everything you can do in C/C++, they simply are safe by default.
Why do we need safety belts and airbags? Can't people just drive carefully?
Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications.
Yes, indeed, we know exactly what kind of code real programmers produce in C and C++: systems full of security holes and buffer overruns. The fact that these bugs keep occurring even though programmers know better is exactly what demonstrates that C/C++ are not up to the task.
As a practical matter, it may help a lot because it makes the machine different from other Linux machines. It may be not too hard conceptually to work out how to break through this kind of security, it will likely protect systems from common exploits of common bugs.
However, in the long term, the only solution I see to security problems is to build on foundations that have support for guarding against common bugs and analyzing security-related program properties. That means, among other things, using languages with built-in default checks for buffer overruns and using languages with type systems that can be used to verify that data doesn't get where it isn't supposed to get (Perl's notion of "tainted" is a simple runtime example; similar static type checking is also possible in some cases). Decades of UNIX, Windows, and Linux software development and bug tracking have shown that without such support, even skilled programmers simply cannot write software containing very serious security problems in actual releases. In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.
Some banks issue ATM and credit cards with sequential or nearly sequential numbers, and they may not require activation for some of the cards. Someone getting a card can make a guess at the next numbers in the sequence and start charging. This is apparently what happened to a card I got when I opened a new account: before I had even opened the envelope, several thousand dollars were gone. Sometimes, the stupidity of some of those supposedly security-conscious money institutions is just amazing.
I suspect Microsoft probably just doesn't see any value in this. Right now, they likely perceive the market as small. And if the market ever got big, that would just mean that their desktop monopoly was threatened. What possible reason would they have to port?
And, frankly, do we really want it? MS Office on Linux would completely wipe out all the other efforts. Sure, Linux would get more commercial users, but they would all be just as tied to Microsoft as they are now. I'd rather see less adoption of Linux and more open source efforts.
Rearranging the color pixels for color stealing is a reasonable idea, and making blue a little bigger is a nice tweak. Is it worth it? That's difficult to say. Subpixel rendering using color stealing on current LCDs actually does roughly put the extra resolution where you want it for high resolution text--vertical lines are the problem in small text, no horizontal lines.
If you want some graphics and multiple windows, X11 is actually not that heavy-weight, although Gnome and KDE are. Consider running plain X11 with "twm", "fvwm", or Oroborus. Of those, "twm" is ubiquitous, while oroborus is a little more modern. For minimal graphical web browsing, consider the "dillo" web browser, although it won't work on complex sites. You could also download Opera, although it's commercial.
Standardization and centralization create bottlenecks. What we need is a more flexible way of putting together lots of different drivers and kernel modules to make a kernel, something that doesn't involve a top-level makefile and a big include tree and lots of version numbers and symbol addresses. Think of how any command line program fits into the shell environment and can potentially be used with any other. That's the kind of composability we need for the kernel. It's what Mach tried for (whether it achieved it is another matter).
Physical security--how quaint. Even if you greatly overengineer it, a widely distributed network of nodes using cryptographic techniques is likely to be much cheaper and no less secure. And it's also likely to be more resilient.
The method has been previously described (using faces) by PassFace and RealUser, and they are trying to commercialize it.
I agree that that's a big problem. At the root is the kernel architecture. What we need is a flexible component architecture that allows people to distribute drivers and other kernel components without being tied tightly to exact version of the kernel. If the Linux kernel developers are unable to do this, maybe the Linux kernel needs to go--unlike GUIs, there are many open source alternatives available.
Besides, given that the majority of Americans have no savings or are deeply in debt, maybe they aren't so terrified after all by a major screwup in bank records.