I strongly disagree. The combination of the Kinesis keyboard and a good keyboard drawer have enabled me to go from near crippling tendonitis in both wrists to pain free. But the keyboard drawer was essential to get the correct posture.
The logitech thumb operated trackball makes a good mouse replacement (once you adapt to it, even drawing with it is possible). But with a good keyboard drawer that provides an elevated mouse pad next to the keyboard, I've found mousing can be quite painless.
3-Com built Lan Manager (SMB v 2), based on Microsoft's MS-NET (SMB v 1). Microsoft jointly marketed it, and had rights to all the code. Novell kicked their asses, so Microsoft bundled LAN manager into NT (SMB v 3). 3-Com lost.
Case 2:
MS marketed DCA's Com Server SNA Gateway under the Microsoft brand name on OS/2. When NT came out, they released a Microsoft product with Com Manager compatible interfaces: SNA Server. DCA lost.
Wake up, Jerry. This is one tough, smart business we are talking about. You can be sure that OS/2 vs. Windows NT was the same. Don't forget, Windows NT started out its life as OS/2 version 3, and Win16 on NT as the "PortHole" environment to let user's run their crufty old Windows 3.0 binaries on OS/2.
I did a windowing fix in a port of some Fortran software from PrimeOS to VAX-VMS. It was at most in 1986. The base of the window was 1985, so it was probably in 1985. Too bad it wasn't 1980, though.
http://howto.linuxberg.com/rfc/rfc1178.txt has some good advice on naming. And, after all, its an internet RFC:) The best advice involves not using people's names for machines: "John's hard drive just crashed."
Anyone seriously considering using an OSS RTOS should look at eCos and RTEMS, as well as EROS. Search/. for more info, and check out eCos at http://www.cygnus.com. And no, I don't work for Cygnus. Here are some facts about eCos: 1. Open sourced under the ECPL, whose terms are quite like the LGPL. Since RTOS's normally get linked with the application, this is important for commercial users. 2. Ported to many hardware platforms. Many of the ports are supported by Cygnus, and there are additional user contributed ports. 3. A TCP/IP stack has been contributed. Last time I checked, this still hasn't made it to the FTP site yet. 4. Cygnus has some pretty good people supporting the open source on the mailing list, in addition to paid support. 5. There is a simulator which runs on top of Linux. This allows you to debug the OS (except the hardware abstraction layer, or HAL) and your application using GNU tools.
IBM was rumoured to be working on a microkernel OS that would run Windows, OS/2 and AIX applications, using intel emulation in a new version of the PowerPC. Maybe transmeta can realize this on their processor.
Without the OEM diskette, can't load Window 95 without: 1. Load DOS 3.3 off 5 1/4" floppies (6 or so). 2. Load DOS 5 upgrade off 3 1/2" floppies (5). 3. Load Windows 3.1 off floppies (5 or so). 4. Install Win 95 off CD.
(Eventually, someone points out you can bare install off DOS 5 upgrade).
DOS 5 diskette gets an error. Crap! Finally get a copy of an OEM diskette for another machine from the guy at the computer store. Guess how to get it to work for my computer (shades of Linux X Config). It works!
Somewhat easier than my last Linux install, but that was RH 5.2. Linux ain't so bad if you give it its own drive.
"that Linux is about to fragment and we need Cygnus to save us... is just plain stupid"
They did say *embedded* Linux. And they're right. There are RT-Linux, KURT, Embedix, Lineo and Hard Hat, to name a few. Linux proper has Linus and Ulrich (maintainer of glibc 2.x and a Cygnus employee) keeping the API unified, but this is not the case in embedded Linux land.
"Maybe you need flash-disk drivers or real-time scheduling."
Actually, Linux has had real-time scheduling since 2.0, at least. And there are flash-disk drivers too, at least on the PowerPC.
"this press release portrays that as the savior of the embedded-linux world, and that's just degrading."
A bit spin-doctored, all right, but you can't blame them. Their just trying to hitch eCos to the Linux band-wagon. They've put a ton of effort into EGCS and glibc, so I guess they deserve a break:)
To quote their license: "RTEMS is free software; you can redistribute it and/or modify it under terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version." Later in the license, they go on to say: "As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."
I'm assuming the reasoning is that you can then use RTEMS with GPLd code (Linux drivers, for example). The problem is, this may be legally questionable. I'm not a lawyer, but I would talk to one before embedding any GPLd code in a proprietary product, even with this "special exemption". Why didn't they allow the option of using the LGPL or the GPL? This would seem to achieve the same goal.
Most RTOSs today do indeed take advantage of the MMU. For example, the MMU is used to control whether a given page of memory is copy-back cached, write through cached, or non-cached. As well, some RTOSs distinguish between supervisory and user mode, and use the MMU to control access to kernel data structures from user code.
What they don't have (as a rule) is a process model. Everything runs as a bunch of kernel tasks, or as a bunch of threads in one big user process. At the high end, there are RTOSs (e.g. LynxOS and embedded Linux) which have a full process model, but allow memory locking and preemptive scheduling.
Working in the embedded space takes a different mind set. Linux can definately be used in some cases, but its resource heavy compared to any RTOS I've looked at. Even LynxOS is highly configurable in terms of allowing you to pare the kernel down to a bare minimum. Of course, with Linux source code, anything's possible...
On NT, Mentor Graphics Microtec compilers for VRTX run under nutcracker, which is a Unix (Korn) shell (running atop the Win32 subsystem) developed by Mortice Kern Systems. Maybe M$ is going to go after traditional Unix strongholds like (non-desktop) software development. I wish more vendors would move their products to Linux, but at least Solaris is better than NT.
3. Even though I continue to rent it, an "automatic upgrade" of the application renders my data unreadable. Since I never owned it in the first place, there's no way to back out to the working version.
Assuming you're trashing VxWorks, I have to say that their kernel is rock solid. Unfortunately (for them) that's one of the few bright points (aside from GCC, which they add no value to) in an otherwise fairly mediocre (IMO) offering.
Don't be so hard on the MCG. The 8240 is pretty new. I don't even no if they have a product based on it yet. Remember, these guys are only sell boards and computers, not the chips (that's Motorola Semiconductor).
I've used the "crappy" RTOS you mentioned, and was actually able to get working drivers for their boards from the MCG. You're right that they're in the business of selling hardware, but if in the process, they contribute to GNU/Linux, what's the problem. Adopting a wait and see attitude is fine, but hold back on the criticism til there's something to criticize.
While I agree the content in this press realease is lacking, Linux has significant problems in an embedded environment. For example, its memory usage is highly nondeterministic. If they're gonna create a version that can be embedded without running out of memory, that would be nice. Since MP3 players have big fat hard drives, they can run virtual memory. Other embedded applications don't have that luxury.
Remember, if they make extensions to the kernel and glibc, they (at least legally) have to publish their enhancements. Then the guys at Hard Hat Linux can distribute them too. So why not welcome another embedded player to Linux space, instead of crapping all over them. I've dealt with the guys at the MCG for years, and they understand embedded computing.
> C++ is overcomplicated, mostly because it is > too low level and high level at the same time.
This is the same comment that Pascal programmers made about C back in the early 80's. The reason C is so successful (and Pascal is not) is that it can do almost everything that assembly language can do. So, when a generation of people trained in Pascal, FORTRAN and PL/I started doing systems programming, they dumped assembly in favour of C.
I'm betting the same will happen with C++. A new generation of programmers trained in Java will want to write systems code in an object oriented language, but will be prevented from using Java due to its non-deterministic nature. The obvious choice will be C++.
In other words, your perceived weakness is actually a strength.
> It's biggest drawback is that it can obfuscate > inefficiencies in code. What looks like a > simple assign (or memcpy) can end up > serializing and parsing at a high cost.
This is true, but you can just take a look at the assembler listing. The tough part (for me) is figuring out why it thunk to do what it did in the first place.
> The problem starts when sombody else has to > maintain the code. They end up loosing the > advantages of OO code because they either have > inefficient code, or have to study the objects > and their relationships just as deeply as they > would in C.
I disagree. Its always easier to understand *well-written* object oriented code (in C or C++) than structured code (in C or C++). And the warts that result from C's lack of OO constructs obfusicate OO code written in C. Writing efficient code has little or nothing to do with the language. It has much to do with the design and the developer.
> Personally, I find that by the time I dig > through C++ code (for the fabled ease of code > reuse) to check for those problems, it would > have been just as easy to cut/paste C code.
Reuse comes from documenting the reusable code (in C or C++). So, if you have to dig through it, it probably wasn't designed to be reused. Cutting and pasting almost always gives more, buggy (due to cut/paste errors) code that needs to be maintained.
> C++ does have a few nice features. Most of > those seem to be in the process of back-porting > into the C standard.
The only reason to use C++ is its OO features. I hope the structured enhancements do go back into C, but don't know of any case personally when someone used C++ to get these.
> In cases where OO is the right approach, but I > want to make the cost of various operations > quite explicit. The Linux kernal is written > that way.
Actually, if you read the kernel mailing list FAQ, they once did a C++ port, and it was significantly slower due to the quality of the compiler. The other reason they site for use of C is that that's what kernel programmers know, which is currently true.
> That and don't rest your forearm on your chair. > that restricts movement in a bad way.
Not using arm rests can also cause problems, as you then have to hold your arms in the proper position. This can lead to shoulder stress and even bursitis.
David Brin's major objection to Star Wars, other than quality, seems to be its elitist culture/heros. Objecting to these in Star Wars means objecting to: 1. Dune - Paul is destined to be a demi-god, son of a Duke, and becomes emporer. Also in Dune, fear is the mind killer - those who fear are animals. 2. Lord of the Rings - Aragorn is destined to be king, and comes from a master race, the Numenorians. 3. Ender's Game - Ender's entire family become the elite of the galaxy. 4. Nine Princes in Amber - a demi-god story in the first person. 5. Stanger in a Strange Land - talk about a messionic character. 6. Highlander (his example) - born to be kings; we are the princes of the universe. I could go on. Most great science fiction has larger than life characters. There are a few notable exceptions (William Gibson comes to mind). I would strongly argue that the ones that will be remembered (and remain meaningful to future generations) are the ones with a mythic subtext.
Slashdot Mirror
I strongly disagree. The combination of the Kinesis keyboard and a good keyboard drawer have enabled me to go from near crippling tendonitis in both wrists to pain free. But the keyboard drawer was essential to get the correct posture.
The logitech thumb operated trackball makes a good mouse replacement (once you adapt to it, even drawing with it is possible). But with a good keyboard drawer that provides an elevated mouse pad next to the keyboard, I've found mousing can be quite painless.
Case 1:
3-Com built Lan Manager (SMB v 2), based on Microsoft's MS-NET (SMB v 1). Microsoft jointly marketed it, and had rights to all the code. Novell kicked their asses, so Microsoft bundled LAN manager into NT (SMB v 3). 3-Com lost.
Case 2:
MS marketed DCA's Com Server SNA Gateway under the Microsoft brand name on OS/2. When NT came out, they released a Microsoft product with Com Manager compatible interfaces: SNA Server. DCA lost.
Wake up, Jerry. This is one tough, smart business we are talking about. You can be sure that OS/2 vs. Windows NT was the same. Don't forget, Windows NT started out its life as OS/2 version 3, and Win16 on NT as the "PortHole" environment to let user's run their crufty old Windows 3.0 binaries on OS/2.
I did a windowing fix in a port of some Fortran software from PrimeOS to VAX-VMS. It was at most in 1986. The base of the window was 1985, so it was probably in 1985. Too bad it wasn't 1980, though.
http://howto.linuxberg.com/rfc/rfc1178.txt has some good advice on naming. And, after all, its an internet RFC :) The best advice involves not using people's names for machines: "John's hard drive just crashed."
Anyone seriously considering using an OSS RTOS should look at eCos and RTEMS, as well as EROS. Search /. for more info, and check out eCos at http://www.cygnus.com. And no, I don't work for Cygnus. Here are some facts about eCos:
1. Open sourced under the ECPL, whose terms are quite like the
LGPL. Since RTOS's normally get linked with the application,
this is important for commercial users.
2. Ported to many hardware platforms. Many of the ports are
supported by Cygnus, and there are additional user contributed
ports.
3. A TCP/IP stack has been contributed. Last time I checked,
this still hasn't made it to the FTP site yet.
4. Cygnus has some pretty good people supporting the open source
on the mailing list, in addition to paid support.
5. There is a simulator which runs on top of Linux. This
allows you to debug the OS (except the hardware
abstraction layer, or HAL) and your application
using GNU tools.
The logical successor to the Pentium to compete with the K7 would be the Septium. If you overclocked one, you'd have a deviated Septium.
IBM was rumoured to be working on a microkernel OS that would run Windows, OS/2 and AIX applications, using intel emulation in a new version of the PowerPC. Maybe transmeta can realize this on their processor.
Without the OEM diskette, can't load Window 95 without:
1. Load DOS 3.3 off 5 1/4" floppies (6 or so).
2. Load DOS 5 upgrade off 3 1/2" floppies (5).
3. Load Windows 3.1 off floppies (5 or so).
4. Install Win 95 off CD.
(Eventually, someone points out you can bare install off DOS 5 upgrade).
DOS 5 diskette gets an error. Crap! Finally get a copy of an OEM diskette for another machine from the guy at the computer store. Guess how to get it to work for my computer (shades of Linux X Config). It works!
Somewhat easier than my last Linux install, but that was RH 5.2. Linux ain't so bad if you give it its own drive.
Look's like I got here too late! All the pix have been clobbered at Apple's request. Rob, update your headline!
"that Linux is about to fragment and we need Cygnus to save us ... is just plain stupid"
:)
They did say *embedded* Linux. And they're right. There are RT-Linux, KURT, Embedix, Lineo and Hard Hat, to name a few. Linux proper has Linus and Ulrich (maintainer of glibc 2.x and a Cygnus employee) keeping the API unified, but this is not the case in embedded Linux land.
"Maybe you need flash-disk drivers or real-time scheduling."
Actually, Linux has had real-time scheduling since 2.0, at least. And there are flash-disk drivers too, at least on the PowerPC.
"this press release portrays that as the savior of the embedded-linux world, and that's just degrading."
A bit spin-doctored, all right, but you can't blame them. Their just trying to hitch eCos to the Linux band-wagon. They've put a ton of effort into EGCS and glibc, so I guess they deserve a break
To quote their license: "RTEMS is free software; you can redistribute it and/or modify it under terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version." Later in the license, they go on to say: "As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."
I'm assuming the reasoning is that you can then use RTEMS with GPLd code (Linux drivers, for example). The problem is, this may be legally questionable. I'm not a lawyer, but I would talk to one before embedding any GPLd code in a proprietary product, even with this "special exemption". Why didn't they allow the option of using the LGPL or the GPL? This would seem to achieve the same goal.
Most RTOSs today do indeed take advantage of the MMU. For example, the MMU is used to control whether a given page of memory is copy-back cached, write through cached, or non-cached. As well, some RTOSs distinguish between supervisory and user mode, and use the MMU to control access to kernel data structures from user code.
What they don't have (as a rule) is a process model. Everything runs as a bunch of kernel tasks, or as a bunch of threads in one big user process. At the high end, there are RTOSs (e.g. LynxOS and embedded Linux) which have a full process model, but allow memory locking and preemptive scheduling.
Working in the embedded space takes a different mind set. Linux can definately be used in some cases, but its resource heavy compared to any RTOS I've looked at. Even LynxOS is highly configurable in terms of allowing you to pare the kernel down to a bare minimum. Of course, with Linux source code, anything's possible...
On NT, Mentor Graphics Microtec compilers for VRTX run under nutcracker, which is a Unix (Korn) shell (running atop the Win32 subsystem) developed by Mortice Kern Systems. Maybe M$ is going to go after traditional Unix strongholds like (non-desktop) software development. I wish more vendors would move their products to Linux, but at least Solaris is better than NT.
Pure speculation here, but maybe the hard-links in NTFS don't work.
3. Even though I continue to rent it, an "automatic upgrade" of the application renders my data unreadable. Since I never owned it in the first place, there's no way to back out to the working version.
Assuming you're trashing VxWorks, I have to say that their kernel is rock solid. Unfortunately (for them) that's one of the few bright points (aside from GCC, which they add no value to) in an otherwise fairly mediocre (IMO) offering.
Don't be so hard on the MCG. The 8240 is pretty new. I don't even no if they have a product based on it yet. Remember, these guys are only sell boards and computers, not the chips (that's Motorola Semiconductor).
I've used the "crappy" RTOS you mentioned, and was actually able to get working drivers for their boards from the MCG. You're right that they're in the business of selling hardware, but if in the process, they contribute to GNU/Linux, what's the problem. Adopting a wait and see attitude is fine, but hold back on the criticism til there's something to criticize.
Good question.
While I agree the content in this press realease is lacking, Linux has significant problems in an embedded environment. For example, its memory usage is highly nondeterministic. If they're gonna create a version that can be embedded without running out of memory, that would be nice. Since MP3 players have big fat hard drives, they can run virtual memory. Other embedded applications don't have that luxury.
Remember, if they make extensions to the kernel and glibc, they (at least legally) have to publish their enhancements. Then the guys at Hard Hat Linux can distribute them too. So why not welcome another embedded player to Linux space, instead of crapping all over them. I've dealt with the guys at the MCG for years, and they understand embedded computing.
> C++ is overcomplicated, mostly because it is
> too low level and high level at the same time.
This is the same comment that Pascal programmers made about C back in the early 80's. The reason C is so successful (and Pascal is not) is that it can do almost everything that assembly language can do. So, when a generation of people trained in Pascal, FORTRAN and PL/I started doing systems programming, they dumped assembly in favour of C.
I'm betting the same will happen with C++. A new generation of programmers trained in Java will want to write systems code in an object oriented language, but will be prevented from using Java due to its non-deterministic nature. The obvious choice will be C++.
In other words, your perceived weakness is actually a strength.
> It's biggest drawback is that it can obfuscate
> inefficiencies in code. What looks like a
> simple assign (or memcpy) can end up
> serializing and parsing at a high cost.
This is true, but you can just take a look at the assembler listing. The tough part (for me) is figuring out why it thunk to do what it did in the first place.
> The problem starts when sombody else has to
> maintain the code. They end up loosing the
> advantages of OO code because they either have
> inefficient code, or have to study the objects
> and their relationships just as deeply as they
> would in C.
I disagree. Its always easier to understand *well-written* object oriented code (in C or C++) than structured code (in C or C++). And the warts that result from C's lack of OO constructs obfusicate OO code written in C. Writing efficient code has little or nothing to do with the language. It has much to do with the design and the developer.
> Personally, I find that by the time I dig
> through C++ code (for the fabled ease of code
> reuse) to check for those problems, it would
> have been just as easy to cut/paste C code.
Reuse comes from documenting the reusable code (in C or C++). So, if you have to dig through it, it probably wasn't designed to be reused. Cutting and pasting almost always gives more, buggy (due to cut/paste errors) code that needs to be maintained.
> C++ does have a few nice features. Most of
> those seem to be in the process of back-porting
> into the C standard.
The only reason to use C++ is its OO features. I hope the structured enhancements do go back into C, but don't know of any case personally when someone used C++ to get these.
> In cases where OO is the right approach, but I
> want to make the cost of various operations
> quite explicit. The Linux kernal is written
> that way.
Actually, if you read the kernel mailing list FAQ, they once did a C++ port, and it was significantly slower due to the quality of the compiler. The other reason they site for use of C is that that's what kernel programmers know, which is currently true.
My favourites are:
1. Hit "Start" to shut down.
2. Type "Ctrl-Alt-Del" to change your password.
> My pinkie finger's knuckle is quite sensitive,
> such that I now hit backspaces and enters with
> my fourth finger instead.
The Kinesys has both enter and backspace on the
thumb pads - a huge improvement for pinky stress.
> That and don't rest your forearm on your chair. > that restricts movement in a bad way.
Not using arm rests can also cause problems, as
you then have to hold your arms in the proper
position. This can lead to shoulder stress and
even bursitis.
David Brin's major objection to Star Wars, other than quality, seems to be its elitist culture/heros. Objecting to these in Star Wars means objecting to:
1. Dune - Paul is destined to be a demi-god, son of a Duke, and becomes emporer. Also in Dune, fear is the mind killer - those who fear are animals.
2. Lord of the Rings - Aragorn is destined to be king, and comes from a master race, the Numenorians.
3. Ender's Game - Ender's entire family become the elite of the galaxy.
4. Nine Princes in Amber - a demi-god story in the first person.
5. Stanger in a Strange Land - talk about a messionic character.
6. Highlander (his example) - born to be kings; we are the princes of the universe.
I could go on. Most great science fiction has larger than life characters. There are a few notable exceptions (William Gibson comes to mind). I would strongly argue that the ones that will be remembered (and remain meaningful to future generations) are the ones with a mythic subtext.