Will Pervasive Multithreading Make a Comeback? 657
exigentsky writes "Having looked at BeOS technology, it is clear that, like NeXTSTEP, it was ahead of its time. Most remarkable to me is the incredible responsiveness of the whole OS. On relatively slow hardware, BeOS could run eight movies simultaneously while still being responsive in all of its GUI controls, and launching programs almost instantaneously. Today, more than ten years after BeOS's introduction, its legendary responsiveness is still unmatched. There is simply no other major OS that has pervasive multithreading from the lowest level up (requiring no programmer tricks). Is it likely, or at least possible, that future versions of Windows or OS X could become pervasively multithreaded without creating an entirely new OS?"
It makes sense with multi-core cpus (Score:5, Informative)
Re: (Score:3, Insightful)
BeOS had a lot of problems as well, for instance the OS was written in C++, which meant that when you wrote drivers, they had to be in C++. The software loaded fast, because it wasn't very
Re: (Score:3, Informative)
libroot was in C, the api was all c++, but there was still a nearly posix subsystem in place via libroot.
Re: (Score:3, Informative)
This is incorrect -- kernel code under BeOS was written in C. It was possible to use C++ in BeOS kernel mode code if you knew what you were doing and what to avoid (e.g. exceptions) but it wasn't recommended.
If you wanted to write a decent userland app in BeOS, OTOH, C++ was your only real choice.
Re: (Score:3, Insightful)
Re:It makes sense with multi-core cpus (Score:5, Insightful)
An operating system's job is to mediate access to hardware and software resources. The fact that every modern OS is madly bloated is just proof that the world's OS developers are ADHD suburban twits getting lazy and gratuitous with fluffy GUI features, when really they should be focusing on two core things: device drivers and the almighty scheduler.
Just think about it: Windows Vista is, on average, 10% slower than XP for generic tasks and gaming. Why the hell is that ? Someone fucked with the kernel and stuck things in it that don't belong there, like that ever-annoying popup security model.
It's like any other optimization job: you tighten the hell out of the most frequently-called code snippets like the scheduler and memory manager. If your scheduler is so contorted and polluted that it can't even fit in the L1 Cache anymore, you should be beaten with your keyboard!
The BeOS guys probably had a plan, along with some good brains and coding skill, and they stuck to that plan. If a feature isn't in the plan, it doesn't get coded; the system stays lean and fast, and you let the application developers handle all the shiny stuff. That's how it used to be, and still is in some circles... but not Windows nor Linux. That's where we went wrong.
Re:It makes sense with multi-core cpus (Score:5, Informative)
BeOS was new. It didn't have to be compatible with anything. But give it 10 years, and 2 Gazillion hacks to let old software continue to work. Give it hundreds or thousands of features, many of which are probably no longer even used by many people, but still have to be there because some small subset needs them. Give it features built upon other features and security patches upon other patches.
Commercial software vendors seldom have the ability to ship software when it's ready, they have to meet timelines. Look at OS X, each new release cycle takes longer and longer because as the OS matures, it takes more and more time to wade through the existing code to change it. It gets slower because more conditionals have to be added to check for compatibility or security issues, or because it needs to do more than it used to.
Linux (the kernel), on the other hand, seems to get better and better, faster and faster, with each new release. There is a reason for that, though. No commercial pressure to release, they can set an arbitrary release date and simply ship whatever features are ready, and do so relatively frequently because they don't have to worry about a large and complete OS release, just the kernel.
Distro vendors, on the other hand, seem to be taking longer and longer between releases (not counting Debian, which has always been glacial), because as the body of software grows, it takes more and more work to maintain it. Distro quality depends largely upon how long they spend stabilizing releases.
Re: (Score:3, Interesting)
I assume those 8 movies are all small so they all fit in memory and don't let the hard drive become the bottleneck, and low-resolution so they don't engage the tilt bits [auckland.ac.nz]? Vista may be a bit faster than XP, but that doesn't make it a useful operating system for people who want to go where they want to today, rather than go to whichever sandbox Microsoft has approved today.
That being said, I've had multiple HD resolution videos running on my Linux laptop and desktop, flawlessly, on multiple Beryl cube sides
Re:It makes sense with multi-core cpus (Score:4, Insightful)
Oh bullshit. Perfect timing as well. Not five minutes ago my work desktop locked up for 45-60 seconds opening a simple HTML e-mail in Outlook and XP. As has been depressingly common with Windows for ages, having difficulties finding a remote source it simply ignored user inputs to concentrate on a network task presumably requiring well under 1% of the hardware's capabilities. Every Outlook window became unresponsive, as did server-hosted toolbars, etc.. These are architectural design decisions, not 'features' cutting off the use, unless 32-bit colour is now an extreme Windows desktop feature.
Re:It makes sense with multi-core cpus (Score:4, Interesting)
Re:It makes sense with multi-core cpus (Score:4, Informative)
It is! In Qt4; it has transparent thread-safety across signals and slots, making it very easy to write multithreaded Qt4 applications. KDE is a little behind, but KDE4 is still going to be more multithreaded than KDE3.
Re:It makes sense with multi-core cpus (Score:5, Informative)
Re:It makes sense with multi-core cpus (Score:4, Funny)
Multitasking all programs without delay
Open source victory
Re:It makes sense with multi-core cpus (Score:4, Funny)
Re:It makes sense with multi-core cpus (Score:4, Funny)
Shows us all how it is done
Educational.
Way off-topic (Score:3, Interesting)
There's a sign hanging in the restroom here at work, and I just realized it was a haiku.
Isogutomo
kokoro shizukani
te wo soete
soto ni kobosuna
-Matsutake no Tsuyu
Even when hurried
Quiet your heart
Steady with your hand
And don't spill any on the outside
-Mushroom Dew
Beautiful, isn't it? The English version just says, "We aim to please, so please aim."
Re:It makes sense with multi-core cpus (Score:5, Funny)
Not seven? so use gzip
compress the fucker
;)
Re:It makes sense with multi-core cpus (Score:5, Funny)
I don't think so.
Re:It makes sense with multi-core cpus (Score:5, Funny)
Hahahahah! I found an error in your grammar rant, now you look even stupider than the guy you were trying to talk shit about. How does that feel you pedantic ass?
Re: (Score:3, Funny)
And that's not something many
Re: (Score:3, Funny)
And that's not something many
Re: (Score:3, Funny)
I always thought "Be-OS" sounded more gangsta, kinda like bee-yotch or bee-atch or however you spell something that is a slang word.
didn't stop everyone in IT from trying to make fun of me for installing it. I had a friend that developed on the platform, doing some kiosk
type work, which it was well suited for. I had it running the cool particle graphics program, attraction, w
Re: (Score:3, Funny)
But sometimes they don't make sense.
Refrigerator [threadless.com]
That's nothing... (Score:4, Funny)
Amiga beat them all (Score:4, Informative)
Amiga was a multi-tasking, multi-threaded OS, with multiple processors (graphics and I/O were separate co-processors operating on opposite clock cycles from the CPU, and the graphics co-processor could be dynamically loaded with special executable code).
It was so far ahead of it's time that people today still don't believe it existed in the 80's when I tell them about it.
But just because it was better than everything else did not assure it's success. A concept the BeOS fanbois might be familiar with.
Re:Amiga beat them all (Score:5, Insightful)
Re:Amiga beat them all (Score:4, Informative)
Actually, I think the GP probably meant 128KB.
My parents bought a 486SX33 in 1994, and that had 4MB, but in 1985....
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re:Amiga beat them all (Score:5, Informative)
What the heck are you talking about?
Just to be a little more correct here, I'm no hardware engineer but will try to be far more accurate.
The Amiga had a great messaging system in it's OS, you could easily pass messages to other windows and programs in intuition. Further, you had all that ARexx stuff, and you could script programs to interact very easily with it. Basically, every program could listen on it's own ARexx socket for commands from other programs. Of course, there was the poor (read, no) memory protection which made things very unstable if you did not know what you were doing. Despite all this cool stuff, the OS was actually the weakest link. It was rushed. I remember reading specs on the original intended, but non-implemented file system, and it was about as robust as a single user file system could possibly get.
You also had preemptive multitasking (not true co-operative) and a fantastic unified memory architecture with a very fast blitter. Another nice thing was
that the kernel was contained on ROM so that it booted quicker then any other platform of it's day, and still faster then most this day. And all those chips played nice
and were synced to an internal clock that ran on NTSC (or PAL) timings. This, of course, meant that interrupts worked seamlessly, and the chipset was handily compatible with video signals from television equipment. That last thing turned into an incredible boon for the entire film and television industry.
The strength of the Amiga was it's bus and it's architecture. They absolutely nailed so many things in it's design, it really was a thing of beauty.
Re: (Score:3, Informative)
As for downloading files online, back then "online" meant downloading from BBS systems. The closest thing to the internet back then for the average consumer was FidoNet.
http://en.wikipedia.org/wiki/Fidonet [wikipedia.org]
And yes, the lack of an MMU, as well as a lack of FPU, in the CPUs used in the early models was a shame. But it did keep the price of the system wit
Re:Amiga beat them all (Score:4, Insightful)
And I was an amiga fanatic. And, while I held out hope that Commodore would get their act together and provide the features that were rumored and needed (DSP's, retargetable graphics, etc..) I always knew it would never happen. If only Dave Haynie had been allowed to do what he wanted, but then again that probably would have made it too expensive for people to buy.
Re: (Score:3, Informative)
From today's perspective (and even 10 years ago) the Amiga has many limitations. But lets not forget that the Amiga started over 20 years ago! (Boy, I must be getting old...)
Multi-threaded programming was a core feature of the Amiga. The UI, Filesystem, core input management, sound, etc. All were managed via threads. This is what allowed some of the very smooth behaviors that so many still talk about today. (Albeit with some rose colored glasses)
Yes, multi-threaded programming is hard for those w
Microsoft's plan is to keep adding cores... (Score:5, Funny)
Re: (Score:3, Informative)
My expe
Re: (Score:3, Informative)
They never bothered making the OS interface (Explorer) multithreaded, which is why on XP you can still crash Explorer and thus your entire desktop (although Explorer restarts after a few seconds).
Explorer has been multithreaded, well, basically forever. Certainly since at _least_ Windows 2000 and I'd happily wager since Windows 95 and NT4. P>The reason your Desktop disappears if Explorer crashes is because it's Explorer that is responsible for drawing the Desktop (and the Taskbar/Start Menu).
Multithreaded won't be optional any more. (Score:5, Insightful)
It's not entirely the operating system's fault. The biggest advance of BeOS wasn't necessarily just that the kernel was designed to multithread nicely, Be also did their best to force you to write multithreaded code when you wrote a Be application.
I suspect that the first thing that's going to become clearly a performance bottleneck is the applications. And that's not going to be fun, because there's a lot of applications out there and you can't just magically recompile them with threads turned on and see much difference. You need to synchronize the data structures for multiple threads touching them at the same time and split things up so that you can actually keep a decent number of cores busy. This is not trivial when you are talking about an app that somebody wrote single threaded in the mid 90s without any notion that threads might be useful later.
Re:Multithreaded won't be optional any more. (Score:4, Insightful)
As for applications - if you're running 5 applications, multi-cores will help without recompiling assuming the kernel's scheduler is reasonably sane and kernel writers are getting smarter at writing different schedulers. If you are running one single-threaded app, multiple cores aren't going to help you much at all. Of course, the other advantage of multi-threading apps (even on a single core) is that if the app is blocking on one thing (I/O is most common for blocking), the other threads can carry on doing work.
Re:Multithreaded won't be optional any more. (Score:4, Interesting)
Are you serious? The idea is to have all your programs running all the time, and interact with them whenever you want with instantaneous response. Not to mention that most apps people run nowadays either are servers (P2P, LAN Shares, etc), clients that sit around listening to servers (IM) or querying them with frequent regularity (Email Client). And the progression is towards having personal servers that you can connect to using either a local or remote client.
The next generation of computing is going to come from the vast multitude of developers who are accustomed to writing client-server applications applying what they know to computers that behave like a server cluster. They are better equipped to approach the problems and rewards of this architectural progression than the guy who has been working in the traditional application space. Now, that's a generalization that's full of exceptions, but it'll be still be proven true on the wider scale.
Re:Multithreaded won't be optional any more. (Score:4, Insightful)
Are YOU serious? Not one of those applications/services you mention requires much CPU. A single CPU with a good scheduler can easily handle all of that with good responsiveness and little or no loss in overall performance. Well, in the case of Windows XP, it woudl also help to have a sane virtual memory system. A lot of the responsiveness problems you see on Win XP machines (Vista may have addressed this) is because Windows likes to swap apps out to disk when you minimize them. It has very little to do with available CPU power.
-matthew
Predict the futrue? Look at the past. (Score:3, Insightful)
Wow. You seem awful sure of the future. Can I borrow your crystal ball? I'd like to look up next week's lottery numbers...
Looking at history, the computer industry seems to show a remarkable propensity to not learn from experience, and instead keep making the same mistakes over and over a
Re:Multithreaded won't be optional any more. (Score:4, Insightful)
As an aside, I would think that a true micro-kernel based OS would work the best using multi-core. Putting every possible function in a different process would seem to be a better use of a multi-core architecture than to have larger kernels.
Re: (Score:3, Informative)
Sure, the trend towards more cores does imply that an inherently multithreaded OS makes more sense. But on the other hand, the main advantage heard about such pervasive multithreading is 'better responsiveness', and I am not sure that modern OSes are 'unresponsive' - curre
Re: (Score:3, Informative)
I'm guessing you never used BeOS; by comparison Linux looks weak in terms of responsiveness.
Re: (Score:3, Interesting)
iTunes used to be on that list when ripping CDs, but since my last upgrade the CD drive has become the bottleneck. GCC doesn't need to be multithreaded, because I can always add a -j option to my make command and run one instance of it on each code (and a floating spare one or two for when one CPU is waiting for I/O). Final Cut can consume pretty much as much CPU power as it's possible to throw at it,
I hope so (Score:4, Interesting)
Another cool operating system to check out is MenuetOS [menuetos.net]... it is written entirely in Assembly! Very fast boot times and the GUI and eevrything fits easily on a floppy!
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Threading isn't any easier when it is pervasive (Score:5, Interesting)
However, taking only a few cycles to spin up or kill a thread (rather than the 10,000 plus it takes Windows), or perform a context switch, is a significant help. (There used to be an interesting article benchmarking those things on the Be website, but I can't find it any more).
MS have also added some more interesting stuff to the scheduler in Vista, which helps with uninterrupted sound or movie playback, so at least some of that stuff is possible without a complete redesign.
Re: (Score:3, Informative)
Really? Man, tell that to my box running Vista Media Center. Media Center has a helpful (cough) habit of capturing the mouse cursor to the screen running the Media Center app. Hit the Windows key to break out of it and your video playback is interrupted for as much as 20 seconds while Windows struggles to
BeOS rocked! (Score:4, Interesting)
Better than xubuntu (Score:4, Informative)
Check out Beos Max [beosmax.org]
Beos is still a lot of fun on older hardware.
I don't get it (Score:5, Insightful)
Overall, I really don't see anything in BeOS that you don't get as well or better in a modern Linux system. BeOS has some efficiency gains from having been developed from the ground up with little need for backwards compatibility, but that's probably also why it wasn't successful in the market. And threading and scheduling in particular are highly efficient and mature in Linux.
(Not that OS X is basically a hacked NeXTStep; the NeXTStep kernel is Mach, the same kernel that is the basis of the GNU Hurd.)
Re: (Score:3, Insightful)
However, from the user's perspective, it's a very big deal. Having used BeOS a few years ago on what was very modest hardware (even at the time), I can easily say that it felt like it was the fastest and most responsive operating system that I've ever used.
Even Linux on modern hardware doesn't come close to the snappiness of BeOS. You also can't beat the fact that it could boot from BIOS to t
Re: (Score:3)
Re: (Score:3, Informative)
You mean--like every one? Beagle uses it, and so does Nautilus. It's been there for a number of years.
Re:I don't get it (Score:4, Interesting)
So what? Why do you want to put more functionality into the kernel than necessary? You can write user-mode code around inotify for recursive watches--Beagle does just that. If enough people wanted it, it could be wrapped up as a library.
Re: (Score:3, Interesting)
>So what? I can launch 20 applications simultaneously in Linux and have them running in a snap;
Well, I'm using Linux everyday at work, and I tell you: it doesn't feel responsive.
I played with BeOS (quite some time ago now) and it felt smooth, quick, reactive (on a PC ten time less powerful).
> that just isn't a big de
Haiku (Score:5, Funny)
Take the features and port to linux.
New scheduler rules them all.
Speed improvements would increase the desktop performance.
As they would increase performance with services.
Tried (for Windows) and killed (Score:5, Interesting)
Re:Tried (for Windows) and killed (Score:5, Insightful)
Thank Gawd Linux isn't using any relic of an OS [wikipedia.org] that started in the 1970's as its base! No, no, all 100% 21st clean legacy-free implementation there.
On a more serious note, I used Beos myself back in the day. It was definitely more responsive than Win98 was, but not everything was perfect either. The networking implementation absolutely sucked. Oh, it had lots of threads, its just that the threads were not all that beneficial to actual performance. The networking stack and some other forms of processing in the system that handle streams of many relatively similar tasks would probably parallelize better via a pipeline scheme where parallelism is achieved by having independent stages of the pipeline run in parallel (much as CPUs break up the task of executing instructions into a pipeline). The type of parallelism that works best can depend on the application, and the one-size fits all philosophy is not usually correct no matter what the solution is.
Yes (Score:5, Interesting)
I'm a CS grad student at the University of North Carolina. I've never used BeOS, but I'm confident that responsiveness will increase, because the work I'm doing right now is attended to address this very issue.
The thing that makes multi threaded programming so difficult is concurrency control - it's extremely easy for programmers to screw up lock-based methods, deadlocking the entire system. The are newer methods of concurrency control that have been proposed, and the most promising method (in my opinion) is 'Software Transactional Memory' which makes it almost trivial to convert correct sequential code to code that is thread-safe. Currently, there are several 'High Performance Computing Languages' in development, and to my knowledge, they all include transactional memory.
The incredible difficulties involved in making chips faster are precipitating a shift to multicore machines. The widespread prevalence of these machines, coupled with newer concurrency control techniques will undoubtedly lead to an increase of responsiveness.
Re:Yes...well, maybe eventually... (Score:4, Interesting)
If/when the CPU designers currently screaming "more threads, more threads!" at us coders get around to implementing efficient h/w transactional memory, painless fine grain parallelism may become a reality. Until then, STM may be fine for very large applications on systems with huge memories and lots of cores, but probably isn't an option for the average desktop.
But STM does present some intriguing possibilities for distributed parallel environments (think STM + DSM).
Re:Yes...well, maybe eventually... (Score:4, Interesting)
As far as performance the key here is compiler design. Sure in the fully general case STM may be fairly resource intensive but most cases aren't the general case. The hope is that compilers can be improved to natively support STM and recognize where simplifying assumptions can be made.
In other words practical STM is a way to get the compiler to meet the programmer halfway. Compilers can't do auto-parrililization and won't be able to anytime in the foreseeable future but having programmers deal with very low level constructs like locks and semaphores is confusing and a waste of time. This is a nice comprimise to meet in the middle. At least as long as it is used correctly.
Re: (Score:3, Insightful)
Yes, it will help the programmer masses not shoot themselves in the foot, but the overhead in STM is phenomenal, and you're relying on Moore's Law to save you.
If you want a responsive system (running on thread-unfriendly OSs like Windows) there's no substitute for knowing what you're doing.
We currently have some offshore developers who are peppering their code with Thread.Sleep() statements, with sleep values selected so that the code kinda-sorta works on their machines. The
Proof MS set computer industry back (Score:4, Insightful)
Same with BeOS. It had many features, including stability, ease-of-use, and responsiveness that MS-Windows can't seem to find today. Granted, neither can GNU/Linux or Mac OSX, but since they are hardly the predominant OS, I can't really fault them to the same extent.
Anyway, it's an old rant. Never mind the ravings of an oldster who never got over the sopranoing Microsoft gave DR-DOS. Those like me are just bitter our careers turned from fun and interesting to tedious and dull because of Microsoft. Y'all go on and play with your shiny new toys. No, really, don't mind me. I'm just gonna sit up here on my porch and get rip-roaring drunk and talk about the old days, whether anybody's listening or not.
The Intel vs. Motorola Decision (Score:3, Insightful)
IBM made a decision in 1980 to go with the Intel 8088 (8/16 bit) processor instead of the Motorola 68000 (16/32 bit) processor. At the time, the Motorola processor was designed to be the processor of the future. On the other hand, the 8088 was intended to be almost compatible with 8080A assembly code. This created the need for the 8088 segmented architecture, and segments suck.
The use of segment registers set PC development back over a decade. Essentially, all the 80's was spent fighting segmentation
Re: (Score:3, Informative)
It wasn't until MS-Windows 2k that MS-Windows was even close to NeXTStep in features, and the cost was a lack of simplicity.
Depends on what you're measuring. NT had (still has, comparing to OS X) better internals - SMP, fine-grained locking, etc, etc.
Multithreaded Windows (Score:5, Funny)
[BSOD]
. , . . , . . [BSOD]
- . [BS0D]
[BSOD]
. . , . [BS0D]
- . [BSOD]
Ummm... (Score:4, Insightful)
BeOS was a single-user system, if I recall, so that partially reduces the need for the security features that having multiple processes provide.
But beyond that, modern OS's seem to offer a lot more flexibility. They have processes if you want separation of address space, shared memory if you need better performance for communication between threads, threading if you want a shared address space, and user-level threading libraries for the ultimate in performance if you're willing to spend the time to code it properly.
Being able to watch eight movies at a time is a neat trick, but it's not particularly useful, especially when we'll soon have processors with a ridiculous amount of cores on them. With a large number of cores, the overhead of a process context switch is hardly more than that of a thread, since a CPU intensive process can run on its own core.
I think the future of OS's is more likely to be in micro-kernel architectures that can move processes around efficiently to balance the processing load between many CPUs. Or a hybrid microkernel/monolithic architecture that could run the big kernel on one CPU for tasks that require responsiveness, and the rest of the kernel processes balanced between remaining CPU's for throughput.
Is High Performance Computing Really the Goal? (Score:4, Insightful)
Re:Is High Performance Computing Really the Goal? (Score:4, Insightful)
Change programming language instead of OS (Score:4, Insightful)
Well, that's it, read up and then maybe we can get some more interesting Slashdot postings about new computers:)
And it is quite amazing that Sun hasn't picked up on this. Their little Java thingie doesn't scale that well after all:)
Huh. BeOS fast? (Score:3, Funny)
Rose-tinted hindsight... (Score:4, Interesting)
BeOS showed no exceptional capabilities. Both Rhapsody and NT were easily able to run multiple concurrent applications without slowdown, and BeOS was at least as often bottlenecked on I/O.
BeOS was certainly a competent OS design, but the "remarkable" performance was only remarkable when it was compared with the classic Mac OS and mainstream Windows 9x. With those as the "competition", the legend of BeOS has grown over the years, but any contemporary preemptive multitasking OS could do as well.
Re:Question... (Score:5, Funny)
The both got gunned down before we could possibly see any downsides to them.
There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later.
Re:Question... (Score:5, Interesting)
This is good, I like this political stuff:
MS-DOS 1.0 was Herbert Hoover, aloof to the problems of the common man but friend of the engineer in all of us. Also discovered Transformers.
Mac OS 7-8-9, all Franklin Roosevelt, very competent, lead us through difficult times, but left a legacy of programs which have become quite a mixed bag.
Windows 3.1, Dwight Eisenhower, amiable enough, competent, but leaving historians (and many contemporaries) very wanting.
Windows 95 thru ME, Lyndon Johnson, one of the boys, very able at getting things done, but in the end a disaster, rightfully ceding his throne.
Windows NT, Richard Nixon, the archetypal back-room politician, ruthless, and ultimately brought down by little faults, but many believe he was a great president and did much to modernize the Republican Party.
Windows XP, Ronald Reagan, everybody who hates him never met him, he could charm anyone, the Great Communicator. Bought Iranian weapons for contras with drug money.
Mac OS X, Bill Clinton, cheerful and smart, if not the most productive. Known for his speeches.
Re:Question... (Score:5, Insightful)
Re:Question... (Score:4, Insightful)
Re:Question... (Score:5, Funny)
Re:Question... (Score:5, Insightful)
Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.
Re:Question... (Score:4, Insightful)
I lost a bit of change on Be stock. It still pisses me off, because Be had the nucleus of a great idea, but failed to follow through.
Re: (Score:3, Funny)
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
Re:No Maybe Yes (Score:5, Informative)
Re:No Maybe Yes (Score:5, Funny)
Re: (Score:3, Interesting)
What you say may have been true some years ago. Nowadays Linux is far more advanced technically than Windows with respect to multi-threading and even more multi-processor / multi-core support.
E.g. gcc does thread-safe initialization of local static variables -- Visual C++ does not. Linux runs on up to 4096 processor machines -- Windows does not. Linux can be run tickless (to some extend) -- Windows can be not. Linux has support for the SUSv3 realtime API with support for nanosecond resolution timers -- Win
Re:We had different programmers 10 years ago (Score:5, Insightful)
So yes, if you mean "developers of business applications aren't generally hardcore down to the metal programmers," then I'd agree with you. John Carmack and Michael Abrash would be bored out of their skulls working on UI issues for Quicken 2008. And, given their aesthetic sensibilities, they wouldn't necessarily be the best choices (just *try* to balance your checkbook).
But if you mean that great programmers are no longer among us, then I'd say that you should change jobs, because it's more likely that they're simply not around *you*.
Re:We had different programmers 10 years ago (Score:5, Insightful)
While C++, assembly and C might no longer be "cool", it definitely teaches people how to write optimal code, how to debug efficiently, understand a wide variety of computing concepts.
The same college today is too busy teaching C# and Java. While those languages are nice and all, not teaching low level C, C++ and assembly IMO leads to sloppy coders, people who don't understand the byte code generated, people who don't mind wasting system resources because hey
I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed.
Re:We had different programmers 10 years ago (Score:4, Interesting)
Was it more cost effective to have a programmer recode it in C (which includes the required maintenance) or use the less optimal but easier to maintain VB COM? I'm all for using C over C#, Java, and VB, but sometimes you need to look at the situation from a business standpoint.
Re:We had different programmers 10 years ago (Score:5, Insightful)
His reaction likely had little to do with code and alot to do with business. To managment's ears you said "This part is done, but I want to take time and money and re-do it really shiny." Now if craftsmanship meant anything in terms of the sales of software, you may have been listened to. But since the hardware companies are all too quick to step up and offer a new gizmo that will have you computer running "blazing fast", the consumer thinks that the sluggish performance is a hardware problem. The end result of all of this is the management of software companies sees little to no reason to take any more time or money than necessary to make a program clean and efficient.
Re: (Score:3, Insightful)
To be blunt: writing VB business apps in C is usually a stupid idea. Business app requirements change often and usually for nontechnical reasons. C is a low level language. But for business apps you'd only need to manipulate stuff at the "Lego level", not the "molecular level". So why use it?
It's near impossible for a normal company to hire programmers who can _rapidly_ write reason
Re: (Score:3, Interesting)
Concurrent Euclid? Dude, where did you go to school? U of T? In the 80s?
I had the distinct pleasure of having Jim Cordy as a prof when I was an undergrad in the 90s. In particular, studying compilers with the man was the single most
Re:Uh, IRIX anyone? (Score:4, Insightful)
What I'm getting at here is that perhaps we could look to the past for some ideas about multi-threading, and IRIX is not a bad choice at all, particularly since it was Unix-derived, like the Linux we use now, whereas BeOS is not.
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Re: (Score:3, Funny)
1) Look for a job/project you want to do
2) Lie and claim you can do it, and commit to doing it
3) Learn the hard way how to do it. Because you committed to doing it, you can't quit when you get stuck and hate it.
4) Do just a good enough job to impress the people that asked you to do it
5) Do another project, this time doing it the right way (or at least better).
6) Repeat until virtually no one knows much more than you on the topic.
7) Profit!
Re:BeOS was awesome (Score:4, Informative)
Speaking of tech demos, the "book" demo where you put four quicktime movies on the pages of a book and flipped the pages with the mouse, did you ever see that? On a 66MHz BeBox (dual 603e, hardly a speed demon) you could have four 320x240 (biotch!) videos playing on this book. Well, you could only see two at first. But then you flip the page around as you like with the mouse and you can see (part of) four videos playing at once. And the whole thing was quite smooth. The framerate would sometimes degrade but the page still moved smoothly and the rest of the OS was still responsive.
That was the one that really impressed me. They obviously really cared about responsiveness in a way that no one else seems to.