Wow, this whole thread is interesting, I've never heard of 'time limits' on public parking...much less having a cop use chalk in some way to mark your tires to see if you moved or not...I take it this is more of a NE US coastal thing?
No, it's all over the US. In the South, I've seen it in Raleigh, Fayetteville, and Atlanta.
The issue is that metered parking is there for people to, say, go out and get lunch or a haircut or whatever. If you're an employee who's going to be there all day, parking a block or two away isn't a huge deal.
Normally areas are marked "2 hour parking" or whatever. The traffic cops come around and mark the tire treads (_not_ the sides of the tires--they want the chalk in a spot where it wears off as soon as the car moves) with chalk periodically, and if they come back and see a car they'd previously marked has been there for over 2 hours they ticket.
I'd lived in areas that did it for _years_ before someone pointed it out to me.
I thought that for a while Yahoo search was #1 before Google became #1. I knew Yahoo actually went through Inktomi (or however it's spelled) but I thought they were still the most popular for awhile.
Nope, their search was never big in those days. You can go back and look at, say, Inktomi and see that their search numbers weren't dramatically affected when Yahoo started using them or when they switched away.
Now, Yahoo was definitely one of the highest traffic web sites; it's just that their search wasn't a big portion of their traffic.
They're still not compilers. And CPython + Psyco is not a compiler either.
Yes, they are. They translate from one language to another. In the case of Psyco, that language happens to be machine code; in the case of CPython it's bytecode. They also have an interpreter (or runtime, virtual machine, whatever you want to call it) which is no different from, say, C++ having a runtime required in addition to your code (and like C++ you can statically link the runtime into a standalone executable if you want to).
You can also run the compiled bytecode directly (and delete the source code) with CPython if you want to.
FWIW, PyPy has a number of backends (it can generate llvm bytecode, native code, CLI code that can run on a.NET runtime, etc) as well as multiple frontends (Python, Javascript, Lisp, etc).
Neither CPython nor PyPy is a strict interpreter, both of them compile source to byte-code and then act as a virtual machine to run that byte-code.
I think that falls under the standard definition of "interpreter".
I don't. It's a mixed system, with both a compiler and an interpreter. A strict interpreter runs directly on the source code (cf Bash).
Note that a compiler doesn't have to be an ahead-of-time process that generates machine code directly. Many C compilers generate assembly code that is then compiled by a seperate ASM->object code compiler. On many modern machines, even that object code isn't the low-level machine code, the CPU breaks it down into micro-ops on most Intel/AMD machines and things are even murkier on Transmeta machines.
And PyPy has multiple backends; it can generate machine code directly, llvm code, CLI code that runs on a.NET runtime, etc. It also has multiple frontends (for a number of toy languages, and for Lisp, Javascript and others). I don't know if the PyPy JVM back-end is in a workable state, but jython certainly compiles Python to java bytecode.
But even in the case of CPython, it's very similar to the Java model with a compilation phase and an interpreted phase. You wouldn't say that javac isn't compiling if it happened to be in the same binary as the JVM.
So much so that in fact, if I recall, python 2.5 is supposed to have optional type declaration.
No, it doesn't. AFAIK all the Type-SIG and other groups looking at it decided against it and the issue is dead.
Re:Yeah, but that's not what we need.
on
Python-to-C++ Compiler
·
· Score: 2, Informative
Last time I checked, it was the only Python compiler... (CPython is an interpreter, PyPy is also an interpreter
Neither CPython nor PyPy is a strict interpreter, both of them compile source to byte-code and then act as a virtual machine to run that byte-code. PyPy also does some work on compiling to native code on the fly, depending on which version you're using (Armin Rigo's is the most sophisticated on the JIT/native code front, but it's far from stable).
While I largely agree that movies at the high-end of the budgetary scale are ridiculously expensive, HD resolution on a cinema screen simply isn't going to cut it.
Once Upon a Time In Mexico looked pretty darned good on the big screen. There were some small artifacts in very bright spots if you looked for them, but the overall image was great. Certainly good enough image-wise to "cut it" with the general viewing audience.
Doesn't anybody remember how quickly Google came on the scene and supplanted Yahoo search?
Yahoo didn't have a search engine of their own, and even whatever other engines they used to power the search on their site weren't high traffic at all. When Google came on the scene and started dominating search, Yahoo was a link categorization service (similar to modern-day dmoz) and a portal site.
Altavista, Lycos, Excite, and others were Google's main competitors (Altavista having supplanted Lycos as the largest search engine when Google came along).
With current color depths, you can distinguish the difference between adjacent colors (in some limited portions of the field). By taking it to a depth where differences are imperceptible, you make things look smoother.
Essentially you want to have your colors go as deep as you need to to make differences imperceptible, which this (supposedly) does. After that going even deeper would be a waste.
For those interested in retrogaming, there is currently a month-long nethack tournament going on on (but the biggest tournament is the one devnull runs every November).
well, in the simplest sense, laws are merely a basic set of ethics that have been agreed upon by the majority.
Not in general they aren't. Many laws are arbitrary answers to questions that need arbitrary answers. I doubt many people would find it an ethical dilemma which day the vote is held, for instance; the law sets one for practicality's sake. They tend not to be the "sexy, argued in court all the time" laws, but if you actually sit down and read through the federal code (or your municipal code) a huge chunk of it is purely administrative.
the photos the laptop buyer uploaded allege that the seller is homosexual or at least bisexual. In the Holocaust, same-sex people were the third largest minority group persecuted by the nazi (after jews and gipsy)
Not to denigrate any group, simply to ensure that others are not forgotten:
Jews were the largest group persecuted, followed in order by Catholics, Poles, Serbs, the disabled, Roma/Sinti ("gypsy), Freemasons, Communists, homosexuals, and Jehovah's Witnesses. That's assuming you don't include millions of Slavic and Soviet citizens and POWs killed as persecutions per se.
Which is why I think most true tlds are silly and we should be moving away from them..xxx.us is a good idea..xxx for the whole world isn't. There's also a LOT of stuff in.com that should be in.com.us. But that would emphasize the point that the Internet is international, and USians don't like that.
This is backwards..com and.edu are meant to be used by all commercial and educational entities..us should only be used for geographically/politically linked organizations--there's no reason that, say, Microsoft couldn't move from Seattle to New York or New Delhi.
Now,.gov and.mil seem like they should be under.us, but OTOH they're original TLDs and the US Government was responsible for the creation of the internet.:-/
From RFC1480 (written in 1993): Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial)
Obviously "with few exceptions" is no longer true, but the point is that.com and.edu were originally intended to house all qualifying registrants..us is more strictly geographically oriented with a few exceptions:
The US Domain hierarchy is based on political geography. The basic name space under US is the state name space, then the "locality" name space, (like a city, or county) then organization or computer name and so on... In addition to strictly geographically names, some special names are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and COUNTY.
Hey, brainiac. If you'd read TFA, you'd know that a microkernel's user-space driver for the network card could happily crash and be restarted without taking out the rest of the system.
The wireless network driver has never taken down my machine. The hardware gets into an unknown state and has to be power-cycled in order to work again. Until then, unloading/reloading the module does nothing. Since I don't know of a way to power a PCI card down and up without a reboot, "shutdown -r now" is the only option. But aside from the total lack of wireless network connectivity, the machine still works fine.
A microkernel isn't going to help with that. Getting pricier hardware that either isn't flaky or can be seperately restarted would, or possibly a driver bugfix would help.
Tannenbaum claims to have something better. His main purpose is to build a computer so stable that it won't have a reset button. The average time to crash of its operating system will be longer than the average lifetime of the hardware. (As far as anyone can tell) this will cost a bit of speed, but not enough that it will matter. Whether that is better or not is a matter of opinion, but in any case it is way cool.
Except I basically have that already. I honestly can't remember the last time I had a machine crash because of OS failure (as opposed to hardware failure; I've had a flaky wireless network card that would periodically get itself out of whack and require a reboot). My home machine is at around 200 days of uptime, which is when I added a new hard drive. The 4 production web servers at work (database and web servers) range from 299-445 days of uptime, and their last reboots were all for new hardware except the one at 445 days (which is when they were physically relocated). Those are machines that are often under high load on both CPU and memory. None of that is new, either; the usage analysis machines (logging and mining 6 million requests/day) at my last job were both at over 600 days uptime when I left in 2001. All are running monolithic kernels.
On the plus side, though, these machines have working virtual memory (not a trivial thing for most microkernels--witness QNX's struggles in this area). They have fairly broad driver support compared to Minix3, and far more features.
From where I sit, there simply isn't a lot of OS-level reliability to be gained. All of the stability issues I've faced in the last several years (both on the server and the desktop) are in user-space already.
All it takes to dump most IT guys (from a manager's point of view) is turning off their computers and revoking their access. Then you turn on a computer in a lower cost country. It's a nasty fact, but a fact non-the-less. If an IT worker wants to survive, he's going to have to move out of what has essentially become a service industry. Move into on-site support (very limited, I know) or move into management where the IT decisions are made and the sent to India etc. for implementation.
This is utter BS except for a few grunt-level programming jobs. Most of the hard work for developers is in communication, especially in getting firm requirements from the clients (be they internal or external clients), demoing and doing iterative scope refinement, adjusting the programming to fit unforeseen needs, bug-hunting on the business spec level (as opposed to the code level), etc, and the standard skills required to be successful in any business job (knowing business goals and aims and how they fit in with what you're doing, etc).
Actually writing code is less than half of the job even at the big web site companies I've worked at, let alone more sophisticated data mining, business application development, etc positions.
If you look at the numbers, the demand for software engineers is growing dramatically (as are the number of jobs available for them). The demand for entry level programmers is growing, but much more slowly; those are jobs which may be a bit more amenable to outsourcing, though in reality automation is a much larger factor in decreased demand. Also note that software engineers outnumber programmers by almost 2:1 in the US, so the vast majority of development jobs are in the more-skilled sector already, and are also in the faster growing sector.
And even within the programmer sector, _most_ jobs are not amenable to outsourcing.
From BLS: Computer software engineers held about 800,000 jobs in 2004. Approximately 460,000 were computer applications software engineers, and around 340,000 were computer systems software engineers...Computer software engineers are projected to be one of the fastest-growing occupations from 2004 to 2014.
Computer programmers held about 455,000 jobs in 2004...Employment of programmers is expected to grow more slowly than the average for all occupations through the year 2014. Sophisticated computer software now has the capability to write basic code, eliminating the need for many programmers to do this routine work. The consolidation and centralization of systems and applications, developments in packaged software, advances in programming languages and tools, and the growing ability of users to design, write, and implement more of their own programs mean that more of the programming functions can be transferred from programmers to other types of information workers, such as computer software engineers...
Another factor limiting growth in employment is the outsourcing of these jobs to other countries...Programmers are at a much higher risk of having their jobs outsourced abroad than are workers involved in more complex and sophisticated information technology functions, such as software engineering...Nevertheless, employers will continue to need programmers who have strong technical skills and who understand an employer's business and its programming requirements.
I think you should review your history. In particular, investigate KeyKOS back in the early 80s, a microkernel-based operating system which operated for decades, and which hosted a fully binary-compatible UNIX environment. I would say that qualifies for a system of "equivalent features"
Great example.
By design it was impossible for KeyKOS to support variable-sized inodes or disk blocks, partition resizing, etc. Even removable media (floppy disks) were a horrible kludge that often threw the object store into an inconsistent state.
Working core dumps (and I'm talking of user applications, not the kernel) were completely impossible under the KeyKOS design, making debugging very difficult (and they tried to spin that as a positive!).
The checkpoint/transaction manager was a performance nightmare once you had to scale to multiple concurrent processes; single process (which were all KeyKOS generally published benchmarks for, aside from a well-known carefully constructed transaction benchmark explicitly designed to make sure that only completely independent data was ever written to the system) were pretty efficient, but tangled references quickly forced the set of objects that needed to be committed to the ENTIRE SYSTEM once you had a fair number of processes running at once. Disk usage was incredibly inefficient.
Moreover, the checkpoint system wasn't ACID compliant so you didn't get anything useful for all that complexity; in crash recovery situations, a transaction that had already been committed could be replayed multiple times (causing data inconsistencies or worse).
I could go on, but the major point is that all of these problems stemmed directly from the design of the KeyKOS microkernel, and the barriers to solutions were ones that would not have existed in a monolithic kernel.
None of those problems were easily soluable, and the attempt to improve the system in EROS wound up in a development rathole that was eventually abandoned because of systemic complexity and severe performance problems. Attempts to follow it up (notably CaprOS with the EROS code, and Coyotos recoding the design from scratch) also have achieved little to date.
And traditional monolithic kernels are buggy, and unreliable. This too has been proven time and time again. The important question is: what's more important to you, development speed, or reliability?
It's a balance between the two, and in real life the fact that people were choosing Windows 98 over more stable alternatives shows that features (achieved through faster development) are generally preferred over absolute stability.
But in real life, monolithic kernels tend to be more reliable than microkernel systems with equivalent features anyway, so it's not really a question of making that tradeoff by choosing microkernel vs. monolithic kernel; the fact that you can develop faster also means you can fix bugs faster.
The only reason people have a perception of microkernels being more stable is because microkernels are so hard to develop that they tend to stagnate feature-wise, and all stagnant systems that are still maintained tend toward bug-fixing and stability.
Hence all major consumer OSes are monolithic. Some start off with a microkernel approach, but they all move to a monolithic approach (see: MacOS X, Windows NT/XP).
Even most complex embedded systems are monolithic; they'll claim that there's a microkernel, but often that's basically a lie and there's a micro-supervisor that takes care of scheduling 2 monolithic kernels (one for "critical" stuff and the other for bells and whistles), which is really not very different from, say, RTLinux.
Now, for simple systems microkernel systems are often an excellent choice. But I haven't seen a single one that competes on a per-feature basis with major monolithic kernels successfully without essentially scheduling a monolithic kernel to support all the interesting stuff; QNX is probably the closest, but it's a pretty far cry from a modern Linux, BSD, XP, or MacOS X system feature-wise.
Not really. Unless you're in strict compatibility mode, the only thing those affect is where you start typing. (A)ppend puts you at the end of the line (like hitting Ctrl-e in emacs). (a)ppend puts you after the current character (like hitting Ctrl-n in emacs). (i)nsert puts you before the current character.
Re:"Intelligent" completion
on
Vim 7 Released
·
· Score: 1
It pretty much sucks compared to the old Ctrl-P/N stuff, but it's easy to turn off.
This is like reliving a horrible, traumatic experience all over again.
Watching this in 2003 HURT. Watching it now is a vaguely unsettling reminder of a darker time.
Big Papi, G38, Foulke, Pedro, David Freaking Roberts, Saturn Balls, Manny being Manny, Bellhorn, the Pro, Tek, Trot, Jesus, the Stud Who Hits Bombs, the OC, Timmeh, Timlin, Halloween, Embree, D-Lowe, Curtis the Mechanic, Eyechart, the Embedded Yankee, Buckethead, and the World's Hottest Jew have set us free.
Bucky Dent, Grady Little, and Bill Buckner have no power over us any more.
We're just regular sports fans now, which is exactly what we always wanted to be.
There are Blockbusters that still have the no late fee policy in place? The stores in my area (Southwestern CT, and also a couple that my family on Long Island frequents) got rid of the no late fee policy less than a month after it started because customers were always taking the full week grace period.
All the company-owned Blockbuster stores are no late fees. About 40% of the franchises are no late fee, and only about 150 stores nationwide switched to no late fees and then switched back to late fees.
There are about 4,600 company-owned stores and just over 1,000 franchises, so about 90% of all Blockbuster stores are currently no-late-fee.
Slashdot Mirror
In the states, very few soft drinks actually use sugar. Most use High Fructose Corn Syrup.
High fructose corn syrup is more than 55% fructose, and much of the remainder is glucose, both of which are sugars.
Wow, this whole thread is interesting, I've never heard of 'time limits' on public parking...much less having a cop use chalk in some way to mark your tires to see if you moved or not...I take it this is more of a NE US coastal thing?
No, it's all over the US. In the South, I've seen it in Raleigh, Fayetteville, and Atlanta.
The issue is that metered parking is there for people to, say, go out and get lunch or a haircut or whatever. If you're an employee who's going to be there all day, parking a block or two away isn't a huge deal.
Normally areas are marked "2 hour parking" or whatever. The traffic cops come around and mark the tire treads (_not_ the sides of the tires--they want the chalk in a spot where it wears off as soon as the car moves) with chalk periodically, and if they come back and see a car they'd previously marked has been there for over 2 hours they ticket.
I'd lived in areas that did it for _years_ before someone pointed it out to me.
I thought that for a while Yahoo search was #1 before Google became #1. I knew Yahoo actually went through Inktomi (or however it's spelled) but I thought they were still the most popular for awhile.
Nope, their search was never big in those days. You can go back and look at, say, Inktomi and see that their search numbers weren't dramatically affected when Yahoo started using them or when they switched away.
Now, Yahoo was definitely one of the highest traffic web sites; it's just that their search wasn't a big portion of their traffic.
I suppose you could argue that the CPython bytecode compiler is basically an assembler for the CPython VM.
Still doesn't change the point, though; an assembler is a particular kind of compiler.
They're still not compilers. And CPython + Psyco is not a compiler either.
.NET runtime, etc) as well as multiple frontends (Python, Javascript, Lisp, etc).
Yes, they are. They translate from one language to another. In the case of Psyco, that language happens to be machine code; in the case of CPython it's bytecode. They also have an interpreter (or runtime, virtual machine, whatever you want to call it) which is no different from, say, C++ having a runtime required in addition to your code (and like C++ you can statically link the runtime into a standalone executable if you want to).
You can also run the compiled bytecode directly (and delete the source code) with CPython if you want to.
FWIW, PyPy has a number of backends (it can generate llvm bytecode, native code, CLI code that can run on a
Neither CPython nor PyPy is a strict interpreter, both of them compile source to byte-code and then act as a virtual machine to run that byte-code.
.NET runtime, etc. It also has multiple frontends (for a number of toy languages, and for Lisp, Javascript and others). I don't know if the PyPy JVM back-end is in a workable state, but jython certainly compiles Python to java bytecode.
I think that falls under the standard definition of "interpreter".
I don't. It's a mixed system, with both a compiler and an interpreter. A strict interpreter runs directly on the source code (cf Bash).
Note that a compiler doesn't have to be an ahead-of-time process that generates machine code directly. Many C compilers generate assembly code that is then compiled by a seperate ASM->object code compiler. On many modern machines, even that object code isn't the low-level machine code, the CPU breaks it down into micro-ops on most Intel/AMD machines and things are even murkier on Transmeta machines.
And PyPy has multiple backends; it can generate machine code directly, llvm code, CLI code that runs on a
But even in the case of CPython, it's very similar to the Java model with a compilation phase and an interpreted phase. You wouldn't say that javac isn't compiling if it happened to be in the same binary as the JVM.
So much so that in fact, if I recall, python 2.5 is supposed to have optional type declaration.
No, it doesn't. AFAIK all the Type-SIG and other groups looking at it decided against it and the issue is dead.
Last time I checked, it was the only Python compiler... (CPython is an interpreter, PyPy is also an interpreter
Neither CPython nor PyPy is a strict interpreter, both of them compile source to byte-code and then act as a virtual machine to run that byte-code. PyPy also does some work on compiling to native code on the fly, depending on which version you're using (Armin Rigo's is the most sophisticated on the JIT/native code front, but it's far from stable).
While I largely agree that movies at the high-end of the budgetary scale are ridiculously expensive, HD resolution on a cinema screen simply isn't going to cut it.
Once Upon a Time In Mexico looked pretty darned good on the big screen. There were some small artifacts in very bright spots if you looked for them, but the overall image was great. Certainly good enough image-wise to "cut it" with the general viewing audience.
Doesn't anybody remember how quickly Google came on the scene and supplanted Yahoo search?
Yahoo didn't have a search engine of their own, and even whatever other engines they used to power the search on their site weren't high traffic at all. When Google came on the scene and started dominating search, Yahoo was a link categorization service (similar to modern-day dmoz) and a portal site.
Altavista, Lycos, Excite, and others were Google's main competitors (Altavista having supplanted Lycos as the largest search engine when Google came along).
With current color depths, you can distinguish the difference between adjacent colors (in some limited portions of the field). By taking it to a depth where differences are imperceptible, you make things look smoother.
Essentially you want to have your colors go as deep as you need to to make differences imperceptible, which this (supposedly) does. After that going even deeper would be a waste.
For those interested in retrogaming, there is currently a month-long nethack tournament going on on (but the biggest tournament is the one devnull runs every November).
The current leaderboard is at http://sartak.katron.org/nh/tourney/trophies.html and has links to tournament info (anyone can play!)
well, in the simplest sense, laws are merely a basic set of ethics that have been agreed upon by the majority.
Not in general they aren't. Many laws are arbitrary answers to questions that need arbitrary answers. I doubt many people would find it an ethical dilemma which day the vote is held, for instance; the law sets one for practicality's sake. They tend not to be the "sexy, argued in court all the time" laws, but if you actually sit down and read through the federal code (or your municipal code) a huge chunk of it is purely administrative.
the photos the laptop buyer uploaded allege that the seller is homosexual or at least bisexual. In the Holocaust, same-sex people were the third largest minority group persecuted by the nazi (after jews and gipsy)
Not to denigrate any group, simply to ensure that others are not forgotten:
Jews were the largest group persecuted, followed in order by Catholics, Poles, Serbs, the disabled, Roma/Sinti ("gypsy), Freemasons, Communists, homosexuals, and Jehovah's Witnesses. That's assuming you don't include millions of Slavic and Soviet citizens and POWs killed as persecutions per se.
Which is why I think most true tlds are silly and we should be moving away from them. .xxx.us is a good idea. .xxx for the whole world isn't. There's also a LOT of stuff in .com that should be in .com.us. But that would emphasize the point that the Internet is international, and USians don't like that.
.com and .edu are meant to be used by all commercial and educational entities. .us should only be used for geographically/politically linked organizations--there's no reason that, say, Microsoft couldn't move from Seattle to New York or New Delhi.
.gov and .mil seem like they should be under .us, but OTOH they're original TLDs and the US Government was responsible for the creation of the internet. :-/
.com and .edu were originally intended to house all qualifying registrants. .us is more strictly geographically oriented with a few exceptions:
This is backwards.
Now,
From RFC1480 (written in 1993):
Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial)
Obviously "with few exceptions" is no longer true, but the point is that
The US Domain hierarchy is based on political geography. The basic name space under US is the state name space, then the "locality" name space, (like a city, or county) then organization or computer name and so on...
In addition to strictly geographically names, some special names are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and COUNTY.
Hey, brainiac. If you'd read TFA, you'd know that a microkernel's user-space driver for the network card could happily crash and be restarted without taking out the rest of the system.
The wireless network driver has never taken down my machine. The hardware gets into an unknown state and has to be power-cycled in order to work again. Until then, unloading/reloading the module does nothing. Since I don't know of a way to power a PCI card down and up without a reboot, "shutdown -r now" is the only option. But aside from the total lack of wireless network connectivity, the machine still works fine.
A microkernel isn't going to help with that. Getting pricier hardware that either isn't flaky or can be seperately restarted would, or possibly a driver bugfix would help.
Tannenbaum claims to have something better. His main purpose is to build a computer so stable that it won't have a reset button. The average time to crash of its operating system will be longer than the average lifetime of the hardware. (As far as anyone can tell) this will cost a bit of speed, but not enough that it will matter. Whether that is better or not is a matter of opinion, but in any case it is way cool.
Except I basically have that already. I honestly can't remember the last time I had a machine crash because of OS failure (as opposed to hardware failure; I've had a flaky wireless network card that would periodically get itself out of whack and require a reboot). My home machine is at around 200 days of uptime, which is when I added a new hard drive. The 4 production web servers at work (database and web servers) range from 299-445 days of uptime, and their last reboots were all for new hardware except the one at 445 days (which is when they were physically relocated). Those are machines that are often under high load on both CPU and memory. None of that is new, either; the usage analysis machines (logging and mining 6 million requests/day) at my last job were both at over 600 days uptime when I left in 2001. All are running monolithic kernels.
On the plus side, though, these machines have working virtual memory (not a trivial thing for most microkernels--witness QNX's struggles in this area). They have fairly broad driver support compared to Minix3, and far more features.
From where I sit, there simply isn't a lot of OS-level reliability to be gained. All of the stability issues I've faced in the last several years (both on the server and the desktop) are in user-space already.
Excellent post. Thank you for introducing me to a previously unknown poet. Here's another (very short) example of Masefield's work:
My road calls me, lures me,
west, east, south and north
Most roads lead men homeward,
my road leads me forth.
All it takes to dump most IT guys (from a manager's point of view) is turning off their computers and revoking their access. Then you turn on a computer in a lower cost country. It's a nasty fact, but a fact non-the-less. If an IT worker wants to survive, he's going to have to move out of what has essentially become a service industry. Move into on-site support (very limited, I know) or move into management where the IT decisions are made and the sent to India etc. for implementation.
This is utter BS except for a few grunt-level programming jobs. Most of the hard work for developers is in communication, especially in getting firm requirements from the clients (be they internal or external clients), demoing and doing iterative scope refinement, adjusting the programming to fit unforeseen needs, bug-hunting on the business spec level (as opposed to the code level), etc, and the standard skills required to be successful in any business job (knowing business goals and aims and how they fit in with what you're doing, etc).
Actually writing code is less than half of the job even at the big web site companies I've worked at, let alone more sophisticated data mining, business application development, etc positions.
If you look at the numbers, the demand for software engineers is growing dramatically (as are the number of jobs available for them). The demand for entry level programmers is growing, but much more slowly; those are jobs which may be a bit more amenable to outsourcing, though in reality automation is a much larger factor in decreased demand. Also note that software engineers outnumber programmers by almost 2:1 in the US, so the vast majority of development jobs are in the more-skilled sector already, and are also in the faster growing sector.
And even within the programmer sector, _most_ jobs are not amenable to outsourcing.
From BLS:
Computer software engineers held about 800,000 jobs in 2004. Approximately 460,000 were computer applications software engineers, and around 340,000 were computer systems software engineers...Computer software engineers are projected to be one of the fastest-growing occupations from 2004 to 2014.
Computer programmers held about 455,000 jobs in 2004...Employment of programmers is expected to grow more slowly than the average for all occupations through the year 2014. Sophisticated computer software now has the capability to write basic code, eliminating the need for many programmers to do this routine work. The consolidation and centralization of systems and applications, developments in packaged software, advances in programming languages and tools, and the growing ability of users to design, write, and implement more of their own programs mean that more of the programming functions can be transferred from programmers to other types of information workers, such as computer software engineers...
Another factor limiting growth in employment is the outsourcing of these jobs to other countries...Programmers are at a much higher risk of having their jobs outsourced abroad than are workers involved in more complex and sophisticated information technology functions, such as software engineering...Nevertheless, employers will continue to need programmers who have strong technical skills and who understand an employer's business and its programming requirements.
I think you should review your history. In particular, investigate KeyKOS back in the early 80s, a microkernel-based operating system which operated for decades, and which hosted a fully binary-compatible UNIX environment. I would say that qualifies for a system of "equivalent features"
Great example.
By design it was impossible for KeyKOS to support variable-sized inodes or disk blocks, partition resizing, etc. Even removable media (floppy disks) were a horrible kludge that often threw the object store into an inconsistent state.
Working core dumps (and I'm talking of user applications, not the kernel) were completely impossible under the KeyKOS design, making debugging very difficult (and they tried to spin that as a positive!).
The checkpoint/transaction manager was a performance nightmare once you had to scale to multiple concurrent processes; single process (which were all KeyKOS generally published benchmarks for, aside from a well-known carefully constructed transaction benchmark explicitly designed to make sure that only completely independent data was ever written to the system) were pretty efficient, but tangled references quickly forced the set of objects that needed to be committed to the ENTIRE SYSTEM once you had a fair number of processes running at once. Disk usage was incredibly inefficient.
Moreover, the checkpoint system wasn't ACID compliant so you didn't get anything useful for all that complexity; in crash recovery situations, a transaction that had already been committed could be replayed multiple times (causing data inconsistencies or worse).
I could go on, but the major point is that all of these problems stemmed directly from the design of the KeyKOS microkernel, and the barriers to solutions were ones that would not have existed in a monolithic kernel.
None of those problems were easily soluable, and the attempt to improve the system in EROS wound up in a development rathole that was eventually abandoned because of systemic complexity and severe performance problems. Attempts to follow it up (notably CaprOS with the EROS code, and Coyotos recoding the design from scratch) also have achieved little to date.
And traditional monolithic kernels are buggy, and unreliable. This too has been proven time and time again. The important question is: what's more important to you, development speed, or reliability?
It's a balance between the two, and in real life the fact that people were choosing Windows 98 over more stable alternatives shows that features (achieved through faster development) are generally preferred over absolute stability.
But in real life, monolithic kernels tend to be more reliable than microkernel systems with equivalent features anyway, so it's not really a question of making that tradeoff by choosing microkernel vs. monolithic kernel; the fact that you can develop faster also means you can fix bugs faster.
The only reason people have a perception of microkernels being more stable is because microkernels are so hard to develop that they tend to stagnate feature-wise, and all stagnant systems that are still maintained tend toward bug-fixing and stability.
Hence all major consumer OSes are monolithic. Some start off with a microkernel approach, but they all move to a monolithic approach (see: MacOS X, Windows NT/XP).
Even most complex embedded systems are monolithic; they'll claim that there's a microkernel, but often that's basically a lie and there's a micro-supervisor that takes care of scheduling 2 monolithic kernels (one for "critical" stuff and the other for bells and whistles), which is really not very different from, say, RTLinux.
Now, for simple systems microkernel systems are often an excellent choice. But I haven't seen a single one that competes on a per-feature basis with major monolithic kernels successfully without essentially scheduling a monolithic kernel to support all the interesting stuff; QNX is probably the closest, but it's a pretty far cry from a modern Linux, BSD, XP, or MacOS X system feature-wise.
There's a distinction between append and insert?
Dang. *goes back to sweet, sweet emacs nirvana*
Not really. Unless you're in strict compatibility mode, the only thing those affect is where you start typing. (A)ppend puts you at the end of the line (like hitting Ctrl-e in emacs). (a)ppend puts you after the current character (like hitting Ctrl-n in emacs). (i)nsert puts you before the current character.
It pretty much sucks compared to the old Ctrl-P/N stuff, but it's easy to turn off.
This is like reliving a horrible, traumatic experience all over again.
Watching this in 2003 HURT. Watching it now is a vaguely unsettling reminder of a darker time.
Big Papi, G38, Foulke, Pedro, David Freaking Roberts, Saturn Balls, Manny being Manny, Bellhorn, the Pro, Tek, Trot, Jesus, the Stud Who Hits Bombs, the OC, Timmeh, Timlin, Halloween, Embree, D-Lowe, Curtis the Mechanic, Eyechart, the Embedded Yankee, Buckethead, and the World's Hottest Jew have set us free.
Bucky Dent, Grady Little, and Bill Buckner have no power over us any more.
We're just regular sports fans now, which is exactly what we always wanted to be.
There are Blockbusters that still have the no late fee policy in place? The stores in my area (Southwestern CT, and also a couple that my family on Long Island frequents) got rid of the no late fee policy less than a month after it started because customers were always taking the full week grace period.
All the company-owned Blockbuster stores are no late fees. About 40% of the franchises are no late fee, and only about 150 stores nationwide switched to no late fees and then switched back to late fees.
There are about 4,600 company-owned stores and just over 1,000 franchises, so about 90% of all Blockbuster stores are currently no-late-fee.