It's the only major platform strongly tied to that CPU architecture.
Given that Windows NT (and variants) is currently available on 3-4 different hardware platforms (depending on how you're counting), has in the past been available on 3 more and has been internally ported to at least 2 more, I'm interested in why you think it is "strongly tied" to x86.
Windows NT 3.x and 4.x are not of common interest anymore; NT 5.0 (W2K), 5.1 (XP) and 6.0 (Vista) are tied IMO to the x86 platform, because 99.999999% of worldwide Windows sales are for that platform. With x86, I mean IA-32 (descendants of the 80286 processor, and compatibles), and I64 (which refers to the 64-bit extensions in IA-32), as well as AMD64 (which is also a 64-bit extension of IA-32). That the X-Box 360 runs on a PowerPC CPU is irrelevant, because it doesn't have a mainstream Windows kernel. Windows Component Edition (CE) is highly portable, but supports only a very small subset of the Windows API.
No, unless Microsoft sells Windows Vista for PowerPC processors and other mainstream CPUs that are widely used in the industry, I won't believe they're capable of writing a portable operating system.
The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities.
BTW, someone who was married to a woman of Turkish descent told me once after a visit to Turkey, "hey, don't worry, airports are very popular in Turkey". Hmmmm. Must be a great, prestigious job, working at an airport, huh.
Germany didn't have a proper immigration law for decades, so people who wanted to immigrate had two choices: 1. Either prove they are related to a German, however remote, or 2. Prove they're political refugees in their own country and seek political asylum. Former federal chancellor Helmut Kohl always said "Germany is no immigration country." -- The SPD government that followed after Kohl finally changed the laws. The political asylum law of course has its good implications: People who are pursued by their government because they uttered a word of criticism can find a refuge; but it also means that people who are rightfully persecuted for politically motivated violence, like terrorists, can find a refuge. How can you tell if a political refugee is a terrorist? You can't, until they expose particular behavior.
People with criminal intent used to enjoy various freedoms in Germany. With the introduction of telecommunication law and the "Grosser Lauschangriff" (huge listening attack), that was implemented already by the Kohl government in the mid-90ies, people were alerted to be more careful in what they're doing.
The German Verfassungschutz (constitution protection) tries to watch the movements of suspicious people. Often those people don't even know what's going on until they're caught on their way to a terrorist attack for instance. We have a history of terrorism that reaches as far back as the 1970ies, when the Red Army faction was orchestrating attacks against industry figureheads. So, we had to live with terrorism for almost 40 years. This influenced the way law enforcement operates, and most people know that many operations are basically covert, because if criminals knew they're being watched, they could change their behavior and be harder to observe.
The Constitution Protection also tries to infiltrate suspicious organizations; one noteworthy scandal was when Constitution Protection officials were discovered occupying the highest ranks of the NPD party (nationalist, neo-nazi party).
True terrorists are suspicious of everybody. They don't use phone or e-mail. They personally meet other people and talk things over. Those laws for data caching (Vorratsdatenspeicherung) won't help much against terrorism, except to catch a few of the minor folk who happen to be dumb enough to use public telecommication systems. The only thing these laws achieve is to catch people who think that the internet or the phone system are anonymous, like teens who copy music and computer software that they cannot afford, or immigrants that are oblivious to German law.
I knew some Muslim extremists, and as far as I can tell, they're organized well enough to avoid scrutiny by the government. A former friend of mine got a job at the Frankfurt airport just weeks before the 2001 attack happened, so when I met him after the attacks, I asked him, half-jokingly, "man, where have you been, you terrorist, have you helped with the attacks?" -- This guy used to be not very conformist with Islamic traditions, he loved alcohol, for instance; but after 2001, he changed, and became conformist, like out of the blue. He told me he wouldn't drink alcohol anymore. Some years later, there's no trace left of his family. They moved elsewhere. I only know he's got a job now that takes him around the world as a salesman (he's got talent for that).
Living door-to-door with terrorists, that's what Germany's all about!;-) (j/k)
As far as I've gathered, they're so paranoid, they meet up in person, they would never use phone or e-mail to communicate important information. "Ah, I'm visiting a friend in (insert remote city)" -- how you can tell what's behind such a thing? It could be entirely innocent after all. And still, I guess the Constitution Protection has to wade through a lot of such phone calls like "hey, buddy, may I visit you in couple of days?"
Also, I noticed that a few people lie about their country of origin, "I'm from country XYZ", and a few weeks later say "I'm from country ABC". You really never know who you are dealing with. I guess, Germany is still a heavenly place for unlawful conduct...
It has been around much longer. It started with the Trusted Computing Platform Alliance, which was founded somewhere between 2001 and 2002 (in the Wikipedia article, there's unfortunately not much information about its history. The organization is now called Trusted Computing Group (of course, with an SSL encrypted homepage!;-) ).
The FSF and EFF have been upset about this for a long time, and for a good reason. The initial design of Windows Vista would have included a "trusted kernel" which would've allowed only trusted applications and documents. Luckily, they could not enforce the original design.
That's what RAID is for. Mirroring and/or striping with multiple drives and automatic error correction can make them more reliable. Bad areas of the SDD drive can automatically be excluded from storage by the filing system. That's basically the same thing with hard drives. A hard drive also accumulates bad sectors during its lifetime, and some day, fails completely. SSDs have a higher ruggedness when it comes to environment conditions.
BTW, the version of OpenFirmware that runs on Efika is very, very sophisticated. It even has a virtual machine that runs the BIOS of plug-in cards in x86 emulation, if necessary. (I saw it on the serial terminal when it printed the number of VM cycles spent in the BIOS)
It's the standard self-repair function of Windows that comes with the Microsoft Installer (MSI) facility. Use Add/Remove Programs (ARP) to remove software. It will also remove the MSI package that repairs itself on your next reboot (or whenever it's integrity is checked).
I bought my Efika 5200B for $99 when it was still on regular sale; it still is, it's just through different sales channels.
For us ex-Amiga users, there's currently no hardware alternative, since both MorphOS and AmigaOS 4 require PPC boards; yet, neither of the two has materialized for the Efika yet. (Though, MorphOS 2.0 has been demonstrated on the Efika, it's just not stable yet)
As for the 5121 board, there's been some unofficial announcements, and the official announcement for the new 5123 board seems promising. The price is not really an issue, but of course anything below $100 will be appreciated, I guess!;-)
They're currently working with Chinese firms to mass market their products; this would also lower the prices. The first Efika was already a huge success, I hope the other ones will be equally successful.
The great advantage of the Efika boards is that they run OpenFirmware, which simplifies porting OSes (and creating your own) a lot. It can boot from virtual any device and supports Amiga file systems and partition tables as well as a few others. It's actually pretty good!:-)
The performance of 400 MHz might look like little, but for AmigaOS 4 or MorphOS, that's like what rocket fuel would be for a car. It would run at 1000 mph!;-)
Did you know that the Linux kernel is like, a 1000 times slower than the AmigaOS 4 kernel when it comes to task switching? Message roundtrip time for a 300 MHz CPU was about 4 microseconds; that's nothing spectacular (the old A-1000 achieved that under some circumstances -- interrupt-triggering message port -- with a 7.16 MHz 68000 CPU), but it's good enough for the CPU time wasting OSes of today. And it has virtual memory and memory protection as well. Now the only problem is that Hyperion Entertainment and Amiga Inc. began to battle at court for the rights to AmigaOS 4. And MorphOS 2.0 is still not finished. It's a dog's life. For Amiga users, at least.;-)
But hey, the Efika runs Debian and a dozen of other OSes. That's at least a beginning!:-)
If you want a truly low-power board, check out the EFIKA with Freescale MPC5200B processor. It has lower specs that the board in TFA, but consumes less than 10 watts with hard drive, and has RS-232 serial port, USB and NIC. Systems with Freescale MPC5121 and MPC5123 dual-core CPUs are also in the make (see news section).:)
I'm running an EFIKA 5200B board with ATI 9250 graphics card, hard drive and CD burner with Debian Linux. Installation was via USB stick and serial port.:)
You'd be surprised: Serial ports are still being used in industrial applications. And who doesn't like to connect text terminals to their computer?;) (mainframes still use that, but it's also nice for UN*X boxes when you've got problems with a framebuffer driver or X... really, a null modem cable can be a useful thing!)
And parallel ports are still useful also, many printers still have a Centronics port in addition to the USB port. Often, the parallel port cabling is more reliable (and portable) that USB. Most UN*Xes support parallel port printers, but not all support USB printers properly.:)
For a simple reason : they get history taught in college there. Actually, it's from elementary school to "college" (there's three different school systems after elementary school). In the most difficult system, aimed at future university students, it's possible in the final years to opt out of courses and choose different ones. You can opt out of German, but you cannot opt out of history, IIRC. Yup, we all know our history (or should, at least!;) ).:)
With the sizes of modern CPU caches, one would assume that the cache is big enough to hold the most frequently used parts of the kernel (because we're talking about context-switching between kernel components here).
This matters because the more messages that are passed, the more context switches that are needed. And each context switch takes some time. Which means that microkernels have a throughput disadvantage. Context switches can be as cheap as two machine instructions (loading a task structure pointer into a register, and jumping to a code address). No-one says you have to use the heavy-duty task switching in a kernel. Only when kernel context has been left and user context is entered and vice versa, you have to set up the MMU and other stuff.
BTW, Helios, which was created by Tim King from MetaComCo, after he ported and incorporated TRIPOS into AmigaOS as the 'dos.library' (another fine piece of software, BTW), Helios used a "fire-and-forget" messaging scheme, with message delivery not guaranteed. In the scenario that I described in the parent article, a failure of a TAS instruction to lock a message queue would simply result in a message not being delivered. The disadvantage of that is obviously that information is potentially lost. To alleviate that, there would have to be message-based conversations between kernel threads, so a kernel thread can ask another for a new copy of the information. When a message would not be able to be delivered, it could flag the target queue that incoming data could not be delivered by using another TAS instruction. Then the receiver would know that something has been lost in transit. Critical information, like signals flagged by interrupts, could be signalled using TAS instructions.
The best solution would be a message-based kernel in the style of AmigaOS' "exec.library". Every kernel thread sleeps until events that are interesting to it occur. An interrupt handler would defer handling the interrupt to a kernel thread, and would just signal the kernel thread that something happened. The kernel thread would then interrogate the hardware and generate an event that it would send to subscribers interested in that event. The kernel threads would sleep most of the time, waiting for signals. The message system would be constructed such that a signal is delivered to the kernel thread when a message arrives at its message port. The kernel thread would then scoop the messages from the message port and store them in an internal queue for subsequent processing. This would minimize the time the message queue has to be locked. When a kernel thread has finished processing its messages, it would wait on the port again. This concept was successfully implemented in AmigaOS, which was very fast even on old hardware (7.16 MHz 68000 CPU). The BKL would be similar to 'exec.library's Disable() and Enable() calls, which disabled and enabled all interrupt handling. These were only rarely used on AmigaOS, mainly to make message queue operations atomic in the kernel. In most CPUs, there are test-and-set (TAS) instructions for multiprocessor situations (on x86, there's XCHG for instance). One could even go so far as to keep a backlog of outgoing messages for a kernel thread. If it can't acquire a TAS lock, it would just store the notification request in the kernel thread's pending output queue. The scheduler would automatically wake the kernel thread and would have it test whether it can deliver pending output messages. Of course this requires that when a kernel message port is deallocated, that pending messages have to be removed from all kernel thread queues.
Code like this is not difficult to implement, but it would greatly enhance the speed and reliability of the kernel. Kernel locks would not be required.
If you ever screw up your X configuration, type "X -configure" or "Xorg -configure" as root, when X is not running, and it writes a new X configuration into root's home directory, together with instructions on how to test it. When done, copy it to "/etc/X11/xorg.conf" (or where your X config files are).
Thanks for your interesting thoughts on the GUI issue! (also, thanks for some comments in this subtree, which are equally interesting)
I've been thinking about the very same issues for quite a while now. But although I do not have a solution yet, I think it has to do with how the user experiences the graphical interface.
The Windows Vista GUI is too convoluted, GNOME is too monotone (in default settings), KDE is a bit nicer, but it has a Windows-like feel (in its default settings), MacOS X GUI is nice and simple, but not customizable enough for those who wish to customize, XFCE is quite good, but not feature-complete yet, and X window managers often do nothing more than manage windows, and do not provide desktop functionality.
As an ex-Amiga-user I have some ideas, but of course things have to be modernized. I think the next step in desktop development will be true 3D. But it requires more thinking than things like Compiz, for instance. 3D offers a completely new way of doing things. Things have to be reorganized and remodelled, without having to modify any applications. A multi-tier approach would be interesting, that abstracts the 3D interface away from the application. But there's of course much more to be done to bring the computing experience into a new generation. We're still basically using stuff that has been developed in the 70ies at Rank Xerox...
If Microsoft was serious about standards, they would base Windows on a UN*X kernel (like the BSDs or Linux perhaps), which would save them a lot of money (just like it did for Apple), and concentrate on an open-source effort to make the.NET platform and framework open-source and merge with the Mono project. Then, the.NET platform and libraries should be standardized. After that, Microsoft should port whatever necessary to the OpenOffice platform and make it open-source. This would save Microsoft a lot of money in the future. Instead of concentrating on leeching the blood out of customers, they should sell a new, open-source Windows and Office platform for a cheap distro price and offer free downloads. In the end, they might make more money than before, because they would get more customers, especially in India and China and other highly populated, but low-salary countries. Plus, open-source efforts would not be wasted on the Windows platform. It would just be another UN*X-like platform to choose from.
It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:
Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The.NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).
Note that the Windows API standard was never updated.
The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.
Every standard is behind current developments if standards are not being followed.
If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).
Just read the last sentence of the article:
"We are already looking into the issues raised in that complaint already..." Microsoft is currently facing another EUR 899 million fine for not following EU antitrust regulations ( BBC article ). Recently, I read an article that mentioned explicitly that OOXML is already being investigated as yet another cause of concern. They're looking into it!
Jeeez, I just downloaded the latest AMD and Intel manuals I could get my hands on, and there's been a lot of change in past year alone for Intel!! Thanks for making me aware of it!:) (I haven't checked AMD manuals for approx. 2 or 3 years)
OK, so both AMD and Intel support SSE4.1 now. SSE4.2 is supported only by Intel so far, and SSE5 is supported only by AMD, so far. I'm glad they realized the limitations of the old SSE instructions and added a couple of new ones.
But anyway, if someone were to use SSE4.2 now, they would have to use different code on AMD processors. And still, you'd have to do something if SSE4.2 isn't available on a CPU. So, you can either write conditional code specifically for Intel and AMD CPUs, or just generally test the feature bit for SSE4.2, and do some other algorithms otherwise. This is what I meant when I said that someone might just choose to implement some generic code when a feature is unavailable, and that leads to inferior speed.
The biggest problem is backwards compatibility of optimization strategies. It's fairly to say "OK, I have CPU XYZ, let's ignore all other CPUs". On your CPU XYZ it just happens to be that functions and data have to be aligned on 16-byte boundaries, and certain instructions are now in microcode, being effectively emulated, rather than hardwired. OK, so you choose one optimization strategy based on your CPU's design. However, you ignore that on older CPUs, your code leads to inferior performance, because some of the instructions that are in microcode now, were hardwired then, for instance. Then, a couple months or years later, a new version of CPU XYZ comes up, and your code performs inferior, because the memory alignment now has to be on 32 byte boundaries, and more instructions are emulated in microcode, coincidentially some of which you happened to use. And so on, just saying.
Slashdot Mirror
It's the only major platform strongly tied to that CPU architecture.
Given that Windows NT (and variants) is currently available on 3-4 different hardware platforms (depending on how you're counting), has in the past been available on 3 more and has been internally ported to at least 2 more, I'm interested in why you think it is "strongly tied" to x86.
Windows NT 3.x and 4.x are not of common interest anymore; NT 5.0 (W2K), 5.1 (XP) and 6.0 (Vista) are tied IMO to the x86 platform, because 99.999999% of worldwide Windows sales are for that platform. With x86, I mean IA-32 (descendants of the 80286 processor, and compatibles), and I64 (which refers to the 64-bit extensions in IA-32), as well as AMD64 (which is also a 64-bit extension of IA-32). That the X-Box 360 runs on a PowerPC CPU is irrelevant, because it doesn't have a mainstream Windows kernel. Windows Component Edition (CE) is highly portable, but supports only a very small subset of the Windows API.No, unless Microsoft sells Windows Vista for PowerPC processors and other mainstream CPUs that are widely used in the industry, I won't believe they're capable of writing a portable operating system.
The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities.
BTW, the Turkish military tries to keep the Turkish government free of influence from Islamic extremists that want to implement a god-state.
BTW, someone who was married to a woman of Turkish descent told me once after a visit to Turkey, "hey, don't worry, airports are very popular in Turkey". Hmmmm. Must be a great, prestigious job, working at an airport, huh.
... it's a long story, so please be patient:
;-) (j/k)
...
Germany didn't have a proper immigration law for decades, so people who wanted to immigrate had two choices: 1. Either prove they are related to a German, however remote, or 2. Prove they're political refugees in their own country and seek political asylum. Former federal chancellor Helmut Kohl always said "Germany is no immigration country." -- The SPD government that followed after Kohl finally changed the laws. The political asylum law of course has its good implications: People who are pursued by their government because they uttered a word of criticism can find a refuge; but it also means that people who are rightfully persecuted for politically motivated violence, like terrorists, can find a refuge. How can you tell if a political refugee is a terrorist? You can't, until they expose particular behavior.
People with criminal intent used to enjoy various freedoms in Germany. With the introduction of telecommunication law and the "Grosser Lauschangriff" (huge listening attack), that was implemented already by the Kohl government in the mid-90ies, people were alerted to be more careful in what they're doing.
The German Verfassungschutz (constitution protection) tries to watch the movements of suspicious people. Often those people don't even know what's going on until they're caught on their way to a terrorist attack for instance. We have a history of terrorism that reaches as far back as the 1970ies, when the Red Army faction was orchestrating attacks against industry figureheads. So, we had to live with terrorism for almost 40 years. This influenced the way law enforcement operates, and most people know that many operations are basically covert, because if criminals knew they're being watched, they could change their behavior and be harder to observe.
The Constitution Protection also tries to infiltrate suspicious organizations; one noteworthy scandal was when Constitution Protection officials were discovered occupying the highest ranks of the NPD party (nationalist, neo-nazi party).
True terrorists are suspicious of everybody. They don't use phone or e-mail. They personally meet other people and talk things over. Those laws for data caching (Vorratsdatenspeicherung) won't help much against terrorism, except to catch a few of the minor folk who happen to be dumb enough to use public telecommication systems. The only thing these laws achieve is to catch people who think that the internet or the phone system are anonymous, like teens who copy music and computer software that they cannot afford, or immigrants that are oblivious to German law.
I knew some Muslim extremists, and as far as I can tell, they're organized well enough to avoid scrutiny by the government. A former friend of mine got a job at the Frankfurt airport just weeks before the 2001 attack happened, so when I met him after the attacks, I asked him, half-jokingly, "man, where have you been, you terrorist, have you helped with the attacks?" -- This guy used to be not very conformist with Islamic traditions, he loved alcohol, for instance; but after 2001, he changed, and became conformist, like out of the blue. He told me he wouldn't drink alcohol anymore. Some years later, there's no trace left of his family. They moved elsewhere. I only know he's got a job now that takes him around the world as a salesman (he's got talent for that).
Living door-to-door with terrorists, that's what Germany's all about!
As far as I've gathered, they're so paranoid, they meet up in person, they would never use phone or e-mail to communicate important information. "Ah, I'm visiting a friend in (insert remote city)" -- how you can tell what's behind such a thing? It could be entirely innocent after all. And still, I guess the Constitution Protection has to wade through a lot of such phone calls like "hey, buddy, may I visit you in couple of days?"
Also, I noticed that a few people lie about their country of origin, "I'm from country XYZ", and a few weeks later say "I'm from country ABC". You really never know who you are dealing with. I guess, Germany is still a heavenly place for unlawful conduct
It has been around much longer. It started with the Trusted Computing Platform Alliance, which was founded somewhere between 2001 and 2002 (in the Wikipedia article, there's unfortunately not much information about its history. The organization is now called Trusted Computing Group (of course, with an SSL encrypted homepage! ;-) ).
The FSF and EFF have been upset about this for a long time, and for a good reason. The initial design of Windows Vista would have included a "trusted kernel" which would've allowed only trusted applications and documents. Luckily, they could not enforce the original design.
That's what RAID is for. Mirroring and/or striping with multiple drives and automatic error correction can make them more reliable. Bad areas of the SDD drive can automatically be excluded from storage by the filing system. That's basically the same thing with hard drives. A hard drive also accumulates bad sectors during its lifetime, and some day, fails completely. SSDs have a higher ruggedness when it comes to environment conditions.
BTW, the version of OpenFirmware that runs on Efika is very, very sophisticated. It even has a virtual machine that runs the BIOS of plug-in cards in x86 emulation, if necessary. (I saw it on the serial terminal when it printed the number of VM cycles spent in the BIOS)
It's the standard self-repair function of Windows that comes with the Microsoft Installer (MSI) facility. Use Add/Remove Programs (ARP) to remove software. It will also remove the MSI package that repairs itself on your next reboot (or whenever it's integrity is checked).
I bought my Efika 5200B for $99 when it was still on regular sale; it still is, it's just through different sales channels.
;-)
:-)
;-)
;-)
:-)
For us ex-Amiga users, there's currently no hardware alternative, since both MorphOS and AmigaOS 4 require PPC boards; yet, neither of the two has materialized for the Efika yet. (Though, MorphOS 2.0 has been demonstrated on the Efika, it's just not stable yet)
As for the 5121 board, there's been some unofficial announcements, and the official announcement for the new 5123 board seems promising. The price is not really an issue, but of course anything below $100 will be appreciated, I guess!
They're currently working with Chinese firms to mass market their products; this would also lower the prices. The first Efika was already a huge success, I hope the other ones will be equally successful.
The great advantage of the Efika boards is that they run OpenFirmware, which simplifies porting OSes (and creating your own) a lot. It can boot from virtual any device and supports Amiga file systems and partition tables as well as a few others. It's actually pretty good!
The performance of 400 MHz might look like little, but for AmigaOS 4 or MorphOS, that's like what rocket fuel would be for a car. It would run at 1000 mph!
Did you know that the Linux kernel is like, a 1000 times slower than the AmigaOS 4 kernel when it comes to task switching? Message roundtrip time for a 300 MHz CPU was about 4 microseconds; that's nothing spectacular (the old A-1000 achieved that under some circumstances -- interrupt-triggering message port -- with a 7.16 MHz 68000 CPU), but it's good enough for the CPU time wasting OSes of today. And it has virtual memory and memory protection as well. Now the only problem is that Hyperion Entertainment and Amiga Inc. began to battle at court for the rights to AmigaOS 4. And MorphOS 2.0 is still not finished. It's a dog's life. For Amiga users, at least.
But hey, the Efika runs Debian and a dozen of other OSes. That's at least a beginning!
If you want a truly low-power board, check out the EFIKA with Freescale MPC5200B processor. It has lower specs that the board in TFA, but consumes less than 10 watts with hard drive, and has RS-232 serial port, USB and NIC. Systems with Freescale MPC5121 and MPC5123 dual-core CPUs are also in the make (see news section). :)
:)
I'm running an EFIKA 5200B board with ATI 9250 graphics card, hard drive and CD burner with Debian Linux. Installation was via USB stick and serial port.
You'd be surprised: Serial ports are still being used in industrial applications. And who doesn't like to connect text terminals to their computer? ;) (mainframes still use that, but it's also nice for UN*X boxes when you've got problems with a framebuffer driver or X ... really, a null modem cable can be a useful thing!)
:)
And parallel ports are still useful also, many printers still have a Centronics port in addition to the USB port. Often, the parallel port cabling is more reliable (and portable) that USB. Most UN*Xes support parallel port printers, but not all support USB printers properly.
With the sizes of modern CPU caches, one would assume that the cache is big enough to hold the most frequently used parts of the kernel (because we're talking about context-switching between kernel components here).
Sample implementation in C for a message system that is multiprocessor safe:
/* simple doubly-linked list: */
/* ... add node to list ... */
/* message and message port structure */
/* for automatic targetting */
/* ... */
/* sample task structure for kernel threads */ /* optional */ /* optional */
typedef struct _node_t {
struct _node_t* next;
struct _node_t* prev;
} node_t;
typedef struct _list_t {
node_t head;
node_t tail;
int taslock;
} list_t;
bool addnode( list_t* list, node_t* node ) {
if ( TAS( &list->taslock, 1 ) ) {
return false;
}
return true;
}
typedef struct _msg_t {
node_t node;
int type;
struct _msgport_t* target;
} msg_t;
typedef struct _msgport_t {
list_t msglist;
struct _task_t* sigtask;
int sigmask;
} msgport_t;
bool addmsg( msgport_t* port, msg_t* msg ) {
if ( !addnode( &port->msglist, &msg->node ) ) {
return false;
}
if ( port->sigtask ) {
sig2task( port->sigtask, port->sigmask );
}
return true;
}
typedef struct _task_t {
msgport_t mainport;
msgport_t outqueue;
msgport_t inqueue;
} task_t;
Of course, additional work would be required for automatic inbox/outbox handling that would retry failed queuing attempts.
(BTW, how do you indent code on Slashdot? Is the code tag the right thing (I used it), or do I have to use CSS formatting?)
BTW, Helios, which was created by Tim King from MetaComCo, after he ported and incorporated TRIPOS into AmigaOS as the 'dos.library' (another fine piece of software, BTW), Helios used a "fire-and-forget" messaging scheme, with message delivery not guaranteed. In the scenario that I described in the parent article, a failure of a TAS instruction to lock a message queue would simply result in a message not being delivered. The disadvantage of that is obviously that information is potentially lost. To alleviate that, there would have to be message-based conversations between kernel threads, so a kernel thread can ask another for a new copy of the information. When a message would not be able to be delivered, it could flag the target queue that incoming data could not be delivered by using another TAS instruction. Then the receiver would know that something has been lost in transit. Critical information, like signals flagged by interrupts, could be signalled using TAS instructions.
The best solution would be a message-based kernel in the style of AmigaOS' "exec.library". Every kernel thread sleeps until events that are interesting to it occur. An interrupt handler would defer handling the interrupt to a kernel thread, and would just signal the kernel thread that something happened. The kernel thread would then interrogate the hardware and generate an event that it would send to subscribers interested in that event. The kernel threads would sleep most of the time, waiting for signals. The message system would be constructed such that a signal is delivered to the kernel thread when a message arrives at its message port. The kernel thread would then scoop the messages from the message port and store them in an internal queue for subsequent processing. This would minimize the time the message queue has to be locked. When a kernel thread has finished processing its messages, it would wait on the port again. This concept was successfully implemented in AmigaOS, which was very fast even on old hardware (7.16 MHz 68000 CPU). The BKL would be similar to 'exec.library's Disable() and Enable() calls, which disabled and enabled all interrupt handling. These were only rarely used on AmigaOS, mainly to make message queue operations atomic in the kernel. In most CPUs, there are test-and-set (TAS) instructions for multiprocessor situations (on x86, there's XCHG for instance). One could even go so far as to keep a backlog of outgoing messages for a kernel thread. If it can't acquire a TAS lock, it would just store the notification request in the kernel thread's pending output queue. The scheduler would automatically wake the kernel thread and would have it test whether it can deliver pending output messages. Of course this requires that when a kernel message port is deallocated, that pending messages have to be removed from all kernel thread queues.
Code like this is not difficult to implement, but it would greatly enhance the speed and reliability of the kernel. Kernel locks would not be required.
If you ever screw up your X configuration, type "X -configure" or "Xorg -configure" as root, when X is not running, and it writes a new X configuration into root's home directory, together with instructions on how to test it. When done, copy it to "/etc/X11/xorg.conf" (or where your X config files are).
Thanks for your interesting thoughts on the GUI issue! (also, thanks for some comments in this subtree, which are equally interesting)
I've been thinking about the very same issues for quite a while now. But although I do not have a solution yet, I think it has to do with how the user experiences the graphical interface.
The Windows Vista GUI is too convoluted, GNOME is too monotone (in default settings), KDE is a bit nicer, but it has a Windows-like feel (in its default settings), MacOS X GUI is nice and simple, but not customizable enough for those who wish to customize, XFCE is quite good, but not feature-complete yet, and X window managers often do nothing more than manage windows, and do not provide desktop functionality.
As an ex-Amiga-user I have some ideas, but of course things have to be modernized. I think the next step in desktop development will be true 3D. But it requires more thinking than things like Compiz, for instance. 3D offers a completely new way of doing things. Things have to be reorganized and remodelled, without having to modify any applications. A multi-tier approach would be interesting, that abstracts the 3D interface away from the application. But there's of course much more to be done to bring the computing experience into a new generation. We're still basically using stuff that has been developed in the 70ies at Rank Xerox...
If Microsoft was serious about standards, they would base Windows on a UN*X kernel (like the BSDs or Linux perhaps), which would save them a lot of money (just like it did for Apple), and concentrate on an open-source effort to make the .NET platform and framework open-source and merge with the Mono project. Then, the .NET platform and libraries should be standardized. After that, Microsoft should port whatever necessary to the OpenOffice platform and make it open-source. This would save Microsoft a lot of money in the future. Instead of concentrating on leeching the blood out of customers, they should sell a new, open-source Windows and Office platform for a cheap distro price and offer free downloads. In the end, they might make more money than before, because they would get more customers, especially in India and China and other highly populated, but low-salary countries. Plus, open-source efforts would not be wasted on the Windows platform. It would just be another UN*X-like platform to choose from.
It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:
.NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).
OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)
Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The
Note that the Windows API standard was never updated.
The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.
Every standard is behind current developments if standards are not being followed.
If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).
BTW, have a look at this publication of the European Court. It is the ruling of September 17, 2007 in the antitrust case.
Jeeez, I just downloaded the latest AMD and Intel manuals I could get my hands on, and there's been a lot of change in past year alone for Intel!! Thanks for making me aware of it! :) (I haven't checked AMD manuals for approx. 2 or 3 years)
OK, so both AMD and Intel support SSE4.1 now. SSE4.2 is supported only by Intel so far, and SSE5 is supported only by AMD, so far. I'm glad they realized the limitations of the old SSE instructions and added a couple of new ones.
But anyway, if someone were to use SSE4.2 now, they would have to use different code on AMD processors. And still, you'd have to do something if SSE4.2 isn't available on a CPU. So, you can either write conditional code specifically for Intel and AMD CPUs, or just generally test the feature bit for SSE4.2, and do some other algorithms otherwise. This is what I meant when I said that someone might just choose to implement some generic code when a feature is unavailable, and that leads to inferior speed.
The biggest problem is backwards compatibility of optimization strategies. It's fairly to say "OK, I have CPU XYZ, let's ignore all other CPUs". On your CPU XYZ it just happens to be that functions and data have to be aligned on 16-byte boundaries, and certain instructions are now in microcode, being effectively emulated, rather than hardwired. OK, so you choose one optimization strategy based on your CPU's design. However, you ignore that on older CPUs, your code leads to inferior performance, because some of the instructions that are in microcode now, were hardwired then, for instance. Then, a couple months or years later, a new version of CPU XYZ comes up, and your code performs inferior, because the memory alignment now has to be on 32 byte boundaries, and more instructions are emulated in microcode, coincidentially some of which you happened to use. And so on, just saying.