Christ, SATA2 is 3M Bits/sec! Not bytes, thats about 300MBytes, and I have yet to see a SATA2 drive. Ultra320 (~320MBytes) SCSI has been in common use for 4 or 5 years now, and you can get 12k and 15k drives in ultra320. 10k drives now just showing up in the last couple of years or so for IDE have been around since the mid '90s in SCSI.
The media transfer rates are still around 60Mbytes a second so, so that is just cache transfer speed, for your itty bitty 8 or 16 megs...
Not only that, but the scale of the crimes doesn't compare. Take for example the quest CEO charged with insider trading to the tune of a hundred million dollars or so. He gets max 10 years, these guys get 5 years for copyright infrignment? What was the total $ value? Maybe a few thousand?
I would like to present a new term "Faulty judgement".
Which in my opinion is more acurate. There wasn't anything wrong with the intellegence. People conviently forget the organizations questioning the "intelligence" before the war because they wern't mainstream news outlets which were all busy being a mouthpiece for the administration. The Powell speech before the UN just proves this. It didn't convince anyone at the UN because all the "intelligence" they presented was either hearsay, or renderings of what "could be". Not a single hard fact in the whole thing. In fact I didn't see a single hard fact during the whole "discussion" supporting the white houses position. On the other hand, there was quite a lot of hard evidence that there wern't any weapons, and the logical problems with the "give us your weapons, or we will attack you" argument was a joke. I saw and read letters from numerious _EXPERTS_ saying things like weapon x Sadam had during GF1 has a shelf life of x years, and has long since become inert, and other similar testimonies. Where were these guys on the news? Being covered up thats where.
Repeat after me, the GDI is not part of the kernel, it simply runs in kernel space (AKA higher privledge). Unlike, linux where everything in kernel space is basically compiled against the kernel headers and is bound to a kernel version, NT has both user and kernel mode API's. To say the graphics system is hard wired to the kernel is like saying my hello-world program is part of libc. Moving it back to userspace should be about as hard as it was back in the NT 3.51 timeframe to move it into kernel space.
General motors isn't really a good example. They have plants outside of the US as well. The problem is that they are poorly managed. When compared to Toyota's plants in the US, it simply costs them more to manufacture a vehicle due to poor manufacturing controls and design. This has been changing over the last few years so that GM and Ford are nearly equivilant to the US plants run by Toyota and Honda, when it comes to lenght of time to produce a car.
GM has two real problems. First is that they have an image problem. Their products don't seem to last. This may have changed in the late '90s but that is hard to prove since the quality studies sited are basically initial quality not long term. The long term quality numbers have yet to come in. The second problem is that GM is full of marketing idiots. These people basically are falling for the same thing they fell for in the 70's. They build big "popular" car of the month type automobiles, and advertise them to no end. They fail to invest in smaller vehicles. So everytime the population decides that gas costs to much or that they want to buy a smaller car GM doesn't have an appropriate product to compete against the hondas and toyotas. The big SUV and Truck sales numbers for both Ford and GM are down very significanly. I've heard that Ford sold roughtly 1/2 as many Explorers this year as last. That is why they are hurting, because all their eggs were in that basket.
Accually, I think you need to study your history a little more. FEMA was created in response to a number of state govement fsckups in response to hurricanes. Its goal was to create a central point of managment for large and multistate disasters. It initially is the state goverments responsiblity to plan and deal with such things, but FEMA is there to take over when the state goverment doesn't have the resources. Basically, they are the calvary you call when you are in over your head. The problem is that FEMA is usually a place stuffed with political favorites. This was true until Andrew. After the fskup with Andrew, newly elected Clinton decited to put someone in charge who had knowledge about running a disaster org, in order to avoid looking like Bush Sr. Hence all the "minor" disasters you didn't hear about, and the well run response to ones you did like 9-11. FEMA survived the first few years of Bush because it was so well run under Clinton. The problem really occoured when FEMA got stuffed into DHS. So while its convient, to blame New Orleans, you have to notice that Mississippi was pretty screwed up and they botched their recovery efforts too. People were running around without food or water there as well. It wasn't as noticable on the news because everyone was looking at New Orleans.
Re:Check out Rob Pike's thoughts on code commentin
on
How to Write Comments
·
· Score: 1
You can tell he doesn't know what a programmers editor is for, by his rules for variable/function naming. Plus, he apparently hasn't done much maintence programming. Its rules like he gives out that give maintence programmers nightmares. Any editor worth its salt can autocomplete long variable names. Having multiple word names requires some kind of break especially when there are abreviations. is "startrap" read as "StartRap" or "StarTrap". This is usually just a case of someone who can't type. I find that people used to using star_trap find it easier just to type StarTrap. 99% of the stuf in K&R is bad style and is evident all over unix and the standard C calls. For example sbrk() does what? Once you know its "StackBreak" aka StackLimit() then your fine. Then there is atoi(), strtok() (which is completly fsked up, and doesn't work in MT enviroments) and the many other things any C programmer knows what they do, but forgets the pain of trying to look up how to convert an ascii string to an integer, or find a substring when they had just started programming.
No i'm not encouraging people who have variable/function names like "ArrayIndex" instead of "i" (they should be shot). Rules like he is encouraging cause people to call there variables "maxaddr" instead of "MaxPhysicalBusAddr" when you are a kernel programmer and it could be a virtual address, physical address, pci bus addresss offset etc... Variable function rules should read more like
Be explicit
Don't make up uncommon abreviations
Use a consistent naming convention and stick to it. (underbars for local names, mixed case for class names, suffexes for parameters, whatever floats your boat)
Learn to use your editor so your not affraid of variable names with more than 5 characters
I know this is a M$ hater web site but just about any programmer can learn a thing or two by picking up the "Windows Native API Refrence" and looking at the function names. They are usually pretty long, but its generally pretty easy to understand what they do, and what the parameters they take are. For an example of bad naming conventions just look at the linux kernel source which is full of evil shit for example (not the worst) http://lxr.linux.no/source/kernel/rcupdate.c which has wonderful things like "call_rcu_bh()" "rcu_do_batch()". After you read the half page comment it makes sense, but some of this is just basic stuff. Plus about 50% of the functions in that module don't even have single line comment about what they do, any side effects, locking requirements to call etc...
Comparing a static C binary, with a JIT is sort of silly. Logically comparing a JIT with a C binary compiled with profile based feedback optimization is probably more legitimate.
Secondly, the released Quake engine had a couple of assembly routines. Proving that C wasn't always the best choice, even back then. My understanding is that the versions of quake with assembly loops are roughtly 30% faster than the C only version they are comparing this with.
In the end these sound like good results, I'm continually amazed at how fast java has gotten. The fundamental arch is pretty much broken for generating fast binaries, and it speaks volumes about the quality of the coders writing the JIT engines that they can make a stack based compilation target run fast on modern processors.
Oh, one final thing, did anyone see what C compiler they used for those numbers? I'm currious if it was the same compiler ID originally used, or one of the more modern intel compilers?
This ad-hominem hugely detracts from your message. It sounds to me like you are a bitter and/or suffer from a case of "sour grapes".
Maybe that is the way it comes across, the truth is like many software project linux doesn't have an overall architecture (or even a roadmap) from which enhancments are made. The fact that the VMM, scheduler or any other piece keeps having major parts rewritten is listed as a feature. In my book that simply says the instead of planning for the future and extending into that plan as time progresses, linux is a collection of 'hacks' put together to experment with a particular method for solving the problem. Now if your opinion is that this is good way to develop software, and the resulting issues caused by such changes can be ingnored so be it. Personally, I don't mind ad-hoc development, but the core of the computer is the most CRITICAL part, any performace problems, or stability problems are catastropic. In these cases I would expect slightly more rigor than what the kernel has.
Now if someone were to say, vmm page eviction is a hard problem to get right, lets build a system that lets us play with diffrent eviction algorithms that would be cool. Instead we have the attitude, lets peephole optimize this piece of code and completely replace it in a few months when someone else manages to write a slightly better version, hapazardly replacing everything that might get in the way of the new version. This ignores the fact that code does tend to stabilize over time. Plus people have been writting operating systems for 45+ years now. They are a pretty well understood problem, and the parts that arn't well understood are pretty self contained. It should be easy to build an architecture that is extensable without having to rewrite big pieces to add things like SMP support, modules, or even dynamic device configuration.
We're not expecting vendors to give away their hardware, we just want them to give away the interface to that hardware.
Today, in many cases more development effort goes into the driver than the hardware, sure you can have the specs but, when we release version 1.1 of the hardware, who is going to update the opensource driver to deal with the bugs that got introduced? Who is responsible for the bad benchmarks our hardware gets because the opensource driver can't perform as well as the closed source one we spend money on. The list goes on, all of this to sell maybe 5% more hardware. Its simply not worth it from the perspective of the managment, of most hardware companies that would rather spend a little extra on the next cycle of marketing.
Oh, where do I start... I could talk about every one of your points.. lets just pick a few.. Firstly, the lack of hardware support for things like grandma's web cam, and caching SATA controllers hurts Linux much more than it hurts adaptec or joe blow's web cam co. If linux is to be just used by hackers for hackers that's probably fine. That isn't the impression I get from "linux people" who are constantly whining about lack of hardware support.
Additionally, setting anything into a static position means that development of it ends and stagnates.
Really? Could have fooled me... Windows can still run DOS and Windows applications from 20 years ago, linux can still run application from 10 years ago. When an API is created, usually there are hooks for extending it in the future. I wouldn't say either one has stagnated, over the course of the last 10 years. If that were the case windows wouldn't run on my quad 64-bit athlon.
*You* are expected to support whatever you decide to make. Unfortunately, the linux kernel developers are expected to support YOU, your hardware and everyone else in the world.
But its our brand which gets damaged, when plugged into a linux box, and it works at 1/4 speed, or looses data because the developer who implemented the driver forgot some important edge case.
They really don't care about you and your binary drivers
No, but the weekly calls by linux users asking for them says that Linus and friends are only a small part of the community.
Stick a Knoppix CD in a computer and see how much of the hardware is supported by default. 90% if not more? Include binary-only winmodem/USB ADSL/philips webcam etc. drivers and you get close to 99%.
Sure, linux supports a lot of hardware, but there is a lot it doesn't support, or supports in a seriously half ass way. I would venture a guess that about 40% of the drivers in the kernel don't actually work based on my experience running linux since the early '90s. When I say don't actually work, i'm saying the driver cannot recover from rare hardware error conditions (like FC cable pulls for example), doesn't fully work. Doesn't work in all situations, for example SCSI adapters that work fine with harddrives but don't work with tape drives because they cannot deal with the rare condition of a tape drive returning check conditions and data at the same time. Or, works fine at some fraction of its rated capability. This isn't counting the fact that the kernel developers often break functionality in the kernel drivers when they change stuff and it doesn't get discovered for 6 months, because the developer making the change didn't test the driver that was affected. Now, your average slashdot weeny doesn't see this because they have standard whitebox or dell machines, that are the same as the other 90% of slashdot weenies. In real life there is a vast amount of strange hardware out there, professional audio cards, hardware encryption engines, 4 port fiber channel cards, ficon, 10G ethernet cards, large disk arrays, big memory systems, 10's of different types of system management interfaces for monitoring things like, system ECC soft errors, redundant power supplies status, etc. The list goes on. In many cases the linux driver was written and tested a year ago, a bunch of people are using it in a production environment and it has been broken for 6 months in the mainstream kernels. I was responsible for fixing a number of race conditions in the VMM a couple of years ago, that only occurred with a SMP box that had more than a couple G of RAM (a rarity back then). This was suppose to work, but it didn't because the people with 6G of ram didn't test it with SMP applications and the people with >2 CPU's didn't test with more than a few hundred megs of RAM. Recently I tried bench marking a 3TB disk array in linux, only to discover that it didn't work in over half of the file systems I tried (XFS, Reiser, JFS, ext2, ext3) and in at least one case worked but was so slow it was unusabl
Firstly, I get paid to do driver development. Secondly, I have never worked for a company that willingly said, ok lets open source the drivers we spend thousands of dollars writing and optimizing.
That said, this whole discussion is as silly as the one about not putting a kernel debugger in the main kernel source code. Frankly, linux desperatly needs both a kernel debugger, and an ABI to be a REAL alternative for many customers. It also needs the ABI for driver developers so that we can write a single driver and expect it to work on the dozens of flavors of linux we are expected to support. Saying that everyone should opensource their drivers is like saying food should be free. It isn't going to to happen and wishing for it, won't make it happen any sooner. In the interm, almost all the hardware out there has better support on windows (Our sysadmin can't even get support for major linux distributions, from major hardware vendors, even when they have little linux logos on their hardware and websites) the windows drivers tend, to accually work, and they almost always have better features sets. This isn't going to change as long as the "opensource" community treats hardware vendors that think they have IP in the driver as second class citizens.
Oh, and for people who don't accually work for hardware companies that ship drivers, driver development is often times an expensive process, not because the software engineers are expensive, but because the hardware and software needs to be tested and certified in particular enviroments. There are orders of magnitude more linux distributions this makes it cost orders of magnitude more to test and support than a half dozen windows enviroments, most of which can be tested at microsoft, or one of the major OEM's if the hardware isn't avialable onsite. Putting 10x the money into a market that may be less than 1/10 of sales is not always a good idea, especially when resources are limited. Creating an proper ABI helps to solve this problem.
That said, if the damn linux kernel accually had a real architecture, it could support an ABI, and even isolate itself from rogue drivers. As it is, the kernel arch is pretty much non existant and just a pile of code that tends to behave like a real kernel, except when you try to do something a little outside of the mainstream desktop or small web server enviroment. This was fine when the whole kernel was just a few hundred thousand lines, but given its current size its getting massivly unmaintainable. This is proven by the fact that linux system stability seems to have gotten really bad over the last few years. Getting to a stable system, takes a lot of vendor testing by the likes of Suse, Redhat, etc.
Lastly, the tainted concept works fine for the kernel developers, why not carry it forwared so that any binary driver simply marks the kernel as having a binary module loaded, and uses the standard abstract interfaces instead of linking against all kinds of unneeded kernel crap that just provides the posibility to screw something up.
The smaller mp3 players don't have 60G hd's in them. They have flash, same as the treo. With 1 and now 2GB SD cards are becomming common, so its not like treo's don't have storage capacity. When it comes to battery life, its not cut and dry. The HD based mp3 players have to spin a harddrive, which consumes massive amounts of power spinning up and during the read/seek cycles. That is compared to the amount of power required to passivivly _recieve_ data. Of course transmission is required to make requests and send ACK's but the vast majority of the wireless connection to recieve mp'3 is downstream to the device, which requires little in the way of transmittion power. I have friends who stream mp3's on their treo's (and get cut off for it, unlimited doesn't always mean unlimited apparently). Apparently some of the players work with larger chunks of data. That way the wireless connection is only open for a short period of time to transfer the data then it sits buffered in the memory for an extended period of time waiting for playback.
Over time the bandwidth on these devices will get better as people want to do more and more on them, so I expect that will also improve. The only real limiting factor is the battery life, but I don't expect there is going to be a huge advantage carrying around a harddrive, in terms of battery life.
Wow!!!!! Please provide a link to where I can get a Treo 650 with a 60GB hard drive. I thought the Treo was just a PHONE with only 23 MB of available flash memory. Obviously I don't know shit, and need to get this miracle device.
I think treo type devices are the future. It doesn't need a 60GB hd because it has internet access to your home machine with a 500GB harddrive, and realtime access to sites with far more storage than you will ever be able to carry around in your back pocket.
Well, I use emacs at work, but I don't really like it. I've used VI a lot too. The diffrence is that emacs can be used as a real programmers editor (by definition a programmers editor needs a built in scripting language). I can make it do anything I can imagine and then bind those things to any key I want. In VI I end up writting lots of bash/perl/awk/etc scripts, and shelling out to perform some task. Plus the vi key bindings drive me crazy. I expect certain keys to behave certain ways. In emacs I just remap them to do what I think they should do.
In truth, As I pointed out in an erlier post, emacs lost a lot of its following to the IDE crowd. People who wanted a programmers editor discovered that editors tailor made for particular languages with built in utilities and real syntatic parsing were easier to use. Especially when they are bound to GUI toolkits like Borland C++ and Netbeans. Emacs was a general purpose editing enviroment that takes a bit of pain to setup as a programmers editor but is functional. The IDE's just tend to work, and the good ones have macro languages, and key rebinding just like emacs. I still run GDB from emacs, but the integration isn't nearly as nice as visual studio and its debugger, even with my hacks. With an IDE the fact that your editing or debugging your code is transparent. Given the choice I would bail from emacs and use a real IDE. Given my mostly unix enviroment (all the major unix's with some driver development mixed in), things like kdevelop still doesn't work for me. So I have emacs, and probably will, until I start doing more regular windows programming again, in which case I will use the IDE that comes with whatever development enviroment I'm using.
Oh, and I will continue to show off to vi users when they come in my office by doing fancy reformats and moving around our CVS repository like file boudaries and diffrent cvs versions don't exist. I know enough about vi to know what it can't do and its not hard to find things that are easier in emacs. My.emacs file will also continue to grow as I add cool new things I think up each day while programming my fingers off enough to produce more code than all our vi users here put together.
Those work too, just like in vi. I do have about 30 lines of rebound keys in my.emacs file. I don't know any serious emacs user that doesn't. I like being able to do remote builds on the development server with my editor and other simple things with 1 keystroke. I have rebound the 'delete', 'home', 'end' etc keys behave as I would expect but that took all of 30 seconds to do.
I like Emacs and its brethren, however, I don't do software development in Emacs anymore. Full blown IDEs like Eclipse are really worth the power, especially since they are able to semantically understand source code.
This is emacs primary problem, the type of people who used to use emacs have all moved on to fully integrated IDE's. The people who don't know a programmers editor from a text editor continue to use VI.
This is one of those time I think open source cheerleading is not a good thing. Just because it's an open source digital image editing program doesn't mean it's the same thing as Adobe's flagship product.
You see this because you are a graphical editing "expert". People who are experts in other areas have similar problems with other opensource projects
For example the linux kernel/standard libraries are like this. It works from a perspective where it pieces of functionality needed by a large group of users are there, but when you _NEED_ functionality not covered by posix (or some proprietary linux solution) your sort of left in the dark. My current problem, is how to get the WWN from a fiberchannel adapter in linux. Its basically impossible, but its really easy in windows. Even basic OS services like async IO and control over the OS caching behaviors is non existant. The fsync() system call in linux is still broken from the perspective that its only suppost to flush the file's buffer, not the whole cache.
The list goes on, a lot of people are suckered into the myth pervalent on/. that opensource solutions can replace any commercial one. I think this myth is pervalent because the people pushing it are mostly high school and recent college graduates who are mostly clueless about state of the art commercial programs. After a few years of work they are no longer on/. because they have grown up and are two busy doing real work and having a life to waste time correcting the falsehoods common here and on similar sites.
.NET assholes. I've been running the 64-bit version of windows for a year (2?) or so now. I got it basically the day the early beta came out. Back then the only way to build 64-bit applications for windows was to run 6 and use the DDK compiler with it.
I never really liked the.net versions anyway, so I'm still running 6 with the newer compilers underneth. It feels a lot faster and the keymappings work the way my fingers expect them to. I tried 2005 for a while but couldn't figure out how to get it to behave like 6. A lot of it has to do with the fact that I run the with the screen nearly full of source files, and use the alt-number shortcuts to pop up the errors, and project management windows. This doesn't work in 2005 which is really anoying.
Apple's crude discontinuation of Lisa was just the first in a series of major customer mis-steps by Apple.
Your point is taken, but your are forgetting the Apple II. A computer that kept apple in buisness until the mid '80's when the mac finally started to make money. All during this time apple continued to sell II's into a _LARGE_ market that wanted an updated machine. If instead of focusing on making a new computer they had simply improved the apple II we would all be running 6502 clones instead of x86 clones. Originally apple said the II was a dead end because its processor was only 8 bit, and a bunch of other reasons, which were all proven wrong, when apple released the IIgs. A number or 3rd party vendors that made harddrives, faster CPU's, ram expansion cards etc also proved that apple was just being stupid. I was one of the people who held out for a faster II until I bought a x86 machine.
Hmmp, sounds like your stretching it. Your original post is quite misleading (maybe on purpose). Your second point about sql server and "enterprise" usage would lead someone to believe your talking about a "server" environment. Where you "again" claim to have the same memory limit. Which is about as misleading as is possible? In which case my post was completely valid.
More clueless crap, for Unix to really be the future, it needs to get rid of its legacy bagage and truely become "well understood". Frankly a lot of people think they understand unix because they are stuck in a single process/text based enviroment mindset. In reality the "extensions" made to unix to support current programming models are full of holes.
When RAS, threads, async io, multiple processors, and may other things that really are the "future" (or rather the current state of the art) are well understood by the unix community they will understand what needs to be changed in the model from the 1970's the people claim is Unix. When that happens unix will be the future, but it won't be "Unix" as you know it.
Now for some more concrete examples. Lets start with a simple one. What does the system call "close()" do? Thats right, did you know it can fail? Whats the solution? Try again. Now think about what happens in a multithreaded enviroment with open() happening in other threads. I can't find a link to Linus's comments on this but they are ammusing. The bottom line is that in a threaded POSIX enviroment you have to write code that looks like (in psudo code to remove the specifics):
app_close(filehandle) {
lockmutex(globalopenlock)
while (close(filehandle)!=EBADF);
unlockmutex(globalopenlock) }
If such a simple unix concept as open/close is screwed up by threads, just imagine what happens when you write code to trap percise floating point exceptions, deal with async filesystem IO over an unreliable network, the list goes on. Basically unix is good for certain kinds of applications and absolutly blows chunks for other kinds. Everyone doing a lot of these things has tied themselves to a particular Unix implementation and uses system specific knowledge to solve the problem.
Slashdot Mirror
Christ, SATA2 is 3M Bits/sec! Not bytes, thats about 300MBytes, and I have yet to see a SATA2 drive. Ultra320 (~320MBytes) SCSI has been in common use for 4 or 5 years now, and you can get 12k and 15k drives in ultra320. 10k drives now just showing up in the last couple of years or so for IDE have been around since the mid '90s in SCSI.
The media transfer rates are still around 60Mbytes a second so, so that is just cache transfer speed, for your itty bitty 8 or 16 megs...
Not only that, but the scale of the crimes doesn't compare. Take for example the quest CEO charged with insider trading to the tune of a hundred million dollars or so. He gets max 10 years, these guys get 5 years for copyright infrignment? What was the total $ value? Maybe a few thousand?
"faulty intelligence"
I would like to present a new term "Faulty judgement".
Which in my opinion is more acurate. There wasn't anything wrong with the intellegence. People conviently forget the organizations questioning the "intelligence" before the war because they wern't mainstream news outlets which were all busy being a mouthpiece for the administration. The Powell speech before the UN just proves this. It didn't convince anyone at the UN because all the "intelligence" they presented was either hearsay, or renderings of what "could be". Not a single hard fact in the whole thing. In fact I didn't see a single hard fact during the whole "discussion" supporting the white houses position. On the other hand, there was quite a lot of hard evidence that there wern't any weapons, and the logical problems with the "give us your weapons, or we will attack you" argument was a joke. I saw and read letters from numerious _EXPERTS_ saying things like weapon x Sadam had during GF1 has a shelf life of x years, and has long since become inert, and other similar testimonies. Where were these guys on the news? Being covered up thats where.
Repeat after me, the GDI is not part of the kernel, it simply runs in kernel space (AKA higher privledge). Unlike, linux where everything in kernel space is basically compiled against the kernel headers and is bound to a kernel version, NT has both user and kernel mode API's. To say the graphics system is hard wired to the kernel is like saying my hello-world program is part of libc. Moving it back to userspace should be about as hard as it was back in the NT 3.51 timeframe to move it into kernel space.
General motors isn't really a good example. They have plants outside of the US as well. The problem is that they are poorly managed. When compared to Toyota's plants in the US, it simply costs them more to manufacture a vehicle due to poor manufacturing controls and design. This has been changing over the last few years so that GM and Ford are nearly equivilant to the US plants run by Toyota and Honda, when it comes to lenght of time to produce a car.
GM has two real problems. First is that they have an image problem. Their products don't seem to last. This may have changed in the late '90s but that is hard to prove since the quality studies sited are basically initial quality not long term. The long term quality numbers have yet to come in. The second problem is that GM is full of marketing idiots. These people basically are falling for the same thing they fell for in the 70's. They build big "popular" car of the month type automobiles, and advertise them to no end. They fail to invest in smaller vehicles. So everytime the population decides that gas costs to much or that they want to buy a smaller car GM doesn't have an appropriate product to compete against the hondas and toyotas. The big SUV and Truck sales numbers for both Ford and GM are down very significanly. I've heard that Ford sold roughtly 1/2 as many Explorers this year as last. That is why they are hurting, because all their eggs were in that basket.
Accually, I think you need to study your history a little more. FEMA was created in response to a number of state govement fsckups in response to hurricanes. Its goal was to create a central point of managment for large and multistate disasters. It initially is the state goverments responsiblity to plan and deal with such things, but FEMA is there to take over when the state goverment doesn't have the resources. Basically, they are the calvary you call when you are in over your head. The problem is that FEMA is usually a place stuffed with political favorites. This was true until Andrew. After the fskup with Andrew, newly elected Clinton decited to put someone in charge who had knowledge about running a disaster org, in order to avoid looking like Bush Sr. Hence all the "minor" disasters you didn't hear about, and the well run response to ones you did like 9-11. FEMA survived the first few years of Bush because it was so well run under Clinton. The problem really occoured when FEMA got stuffed into DHS. So while its convient, to blame New Orleans, you have to notice that Mississippi was pretty screwed up and they botched their recovery efforts too. People were running around without food or water there as well. It wasn't as noticable on the news because everyone was looking at New Orleans.
No i'm not encouraging people who have variable/function names like "ArrayIndex" instead of "i" (they should be shot). Rules like he is encouraging cause people to call there variables "maxaddr" instead of "MaxPhysicalBusAddr" when you are a kernel programmer and it could be a virtual address, physical address, pci bus addresss offset etc... Variable function rules should read more like
I know this is a M$ hater web site but just about any programmer can learn a thing or two by picking up the "Windows Native API Refrence" and looking at the function names. They are usually pretty long, but its generally pretty easy to understand what they do, and what the parameters they take are. For an example of bad naming conventions just look at the linux kernel source which is full of evil shit for example (not the worst) http://lxr.linux.no/source/kernel/rcupdate.c
which has wonderful things like "call_rcu_bh()" "rcu_do_batch()". After you read the half page comment it makes sense, but some of this is just basic stuff. Plus about 50% of the functions in that module don't even have single line comment about what they do, any side effects, locking requirements to call etc...
I have two points.
Comparing a static C binary, with a JIT is sort of silly. Logically comparing a JIT with a C binary compiled with profile based feedback optimization is probably more legitimate.
Secondly, the released Quake engine had a couple of assembly routines. Proving that C wasn't always the best choice, even back then. My understanding is that the versions of quake with assembly loops are roughtly 30% faster than the C only version they are comparing this with.
In the end these sound like good results, I'm continually amazed at how fast java has gotten. The fundamental arch is pretty much broken for generating fast binaries, and it speaks volumes about the quality of the coders writing the JIT engines that they can make a stack based compilation target run fast on modern processors.
Oh, one final thing, did anyone see what C compiler they used for those numbers? I'm currious if it was the same compiler ID originally used, or one of the more modern intel compilers?
This ad-hominem hugely detracts from your message. It sounds to me like you are a bitter and/or suffer from a case of "sour grapes".
Maybe that is the way it comes across, the truth is like many software project linux doesn't have an overall architecture (or even a roadmap) from which enhancments are made. The fact that the VMM, scheduler or any other piece keeps having major parts rewritten is listed as a feature. In my book that simply says the instead of planning for the future and extending into that plan as time progresses, linux is a collection of 'hacks' put together to experment with a particular method for solving the problem. Now if your opinion is that this is good way to develop software, and the resulting issues caused by such changes can be ingnored so be it. Personally, I don't mind ad-hoc development, but the core of the computer is the most CRITICAL part, any performace problems, or stability problems are catastropic. In these cases I would expect slightly more rigor than what the kernel has.
Now if someone were to say, vmm page eviction is a hard problem to get right, lets build a system that lets us play with diffrent eviction algorithms that would be cool. Instead we have the attitude, lets peephole optimize this piece of code and completely replace it in a few months when someone else manages to write a slightly better version, hapazardly replacing everything that might get in the way of the new version. This ignores the fact that code does tend to stabilize over time. Plus people have been writting operating systems for 45+ years now. They are a pretty well understood problem, and the parts that arn't well understood are pretty self contained. It should be easy to build an architecture that is extensable without having to rewrite big pieces to add things like SMP support, modules, or even dynamic device configuration.
We're not expecting vendors to give away their hardware, we just want them to give away the interface to that hardware.
Today, in many cases more development effort goes into the driver than the hardware, sure you can have the specs but, when we release version 1.1 of the hardware, who is going to update the opensource driver to deal with the bugs that got introduced? Who is responsible for the bad benchmarks our hardware gets because the opensource driver can't perform as well as the closed source one we spend money on. The list goes on, all of this to sell maybe 5% more hardware. Its simply not worth it from the perspective of the managment, of most hardware companies that would rather spend a little extra on the next cycle of marketing.
Oh, where do I start... I could talk about every one of your points.. lets just pick a few.. Firstly, the lack of hardware support for things like grandma's web cam, and caching SATA controllers hurts Linux much more than it hurts adaptec or joe blow's web cam co. If linux is to be just used by hackers for hackers that's probably fine. That isn't the impression I get from "linux people" who are constantly whining about lack of hardware support.
Additionally, setting anything into a static position means that development of it ends and stagnates.
Really? Could have fooled me... Windows can still run DOS and Windows applications from 20 years ago, linux can still run application from 10 years ago. When an API is created, usually there are hooks for extending it in the future. I wouldn't say either one has stagnated, over the course of the last 10 years. If that were the case windows wouldn't run on my quad 64-bit athlon.
*You* are expected to support whatever you decide to make. Unfortunately, the linux kernel developers are expected to support YOU, your hardware and everyone else in the world.
But its our brand which gets damaged, when plugged into a linux box, and it works at 1/4 speed, or looses data because the developer who implemented the driver forgot some important edge case.
They really don't care about you and your binary drivers
No, but the weekly calls by linux users asking for them says that Linus and friends are only a small part of the community.
Stick a Knoppix CD in a computer and see how much of the hardware is supported by default. 90% if not more? Include binary-only winmodem/USB ADSL/philips webcam etc. drivers and you get close to 99%.
Sure, linux supports a lot of hardware, but there is a lot it doesn't support, or supports in a seriously half ass way. I would venture a guess that about 40% of the drivers in the kernel don't actually work based on my experience running linux since the early '90s. When I say don't actually work, i'm saying the driver cannot recover from rare hardware error conditions (like FC cable pulls for example), doesn't fully work. Doesn't work in all situations, for example SCSI adapters that work fine with harddrives but don't work with tape drives because they cannot deal with the rare condition of a tape drive returning check conditions and data at the same time. Or, works fine at some fraction of its rated capability. This isn't counting the fact that the kernel developers often break functionality in the kernel drivers when they change stuff and it doesn't get discovered for 6 months, because the developer making the change didn't test the driver that was affected. Now, your average slashdot weeny doesn't see this because they have standard whitebox or dell machines, that are the same as the other 90% of slashdot weenies. In real life there is a vast amount of strange hardware out there, professional audio cards, hardware encryption engines, 4 port fiber channel cards, ficon, 10G ethernet cards, large disk arrays, big memory systems, 10's of different types of system management interfaces for monitoring things like, system ECC soft errors, redundant power supplies status, etc. The list goes on. In many cases the linux driver was written and tested a year ago, a bunch of people are using it in a production environment and it has been broken for 6 months in the mainstream kernels. I was responsible for fixing a number of race conditions in the VMM a couple of years ago, that only occurred with a SMP box that had more than a couple G of RAM (a rarity back then). This was suppose to work, but it didn't because the people with 6G of ram didn't test it with SMP applications and the people with >2 CPU's didn't test with more than a few hundred megs of RAM. Recently I tried bench marking a 3TB disk array in linux, only to discover that it didn't work in over half of the file systems I tried (XFS, Reiser, JFS, ext2, ext3) and in at least one case worked but was so slow it was unusabl
Firstly, I get paid to do driver development. Secondly, I have never worked for a company that willingly said, ok lets open source the drivers we spend thousands of dollars writing and optimizing.
That said, this whole discussion is as silly as the one about not putting a kernel debugger in the main kernel source code. Frankly, linux desperatly needs both a kernel debugger, and an ABI to be a REAL alternative for many customers. It also needs the ABI for driver developers so that we can write a single driver and expect it to work on the dozens of flavors of linux we are expected to support. Saying that everyone should opensource their drivers is like saying food should be free. It isn't going to to happen and wishing for it, won't make it happen any sooner. In the interm, almost all the hardware out there has better support on windows (Our sysadmin can't even get support for major linux distributions, from major hardware vendors, even when they have little linux logos on their hardware and websites) the windows drivers tend, to accually work, and they almost always have better features sets. This isn't going to change as long as the "opensource" community treats hardware vendors that think they have IP in the driver as second class citizens.
Oh, and for people who don't accually work for hardware companies that ship drivers, driver development is often times an expensive process, not because the software engineers are expensive, but because the hardware and software needs to be tested and certified in particular enviroments. There are orders of magnitude more linux distributions this makes it cost orders of magnitude more to test and support than a half dozen windows enviroments, most of which can be tested at microsoft, or one of the major OEM's if the hardware isn't avialable onsite. Putting 10x the money into a market that may be less than 1/10 of sales is not always a good idea, especially when resources are limited. Creating an proper ABI helps to solve this problem.
That said, if the damn linux kernel accually had a real architecture, it could support an ABI, and even isolate itself from rogue drivers. As it is, the kernel arch is pretty much non existant and just a pile of code that tends to behave like a real kernel, except when you try to do something a little outside of the mainstream desktop or small web server enviroment. This was fine when the whole kernel was just a few hundred thousand lines, but given its current size its getting massivly unmaintainable. This is proven by the fact that linux system stability seems to have gotten really bad over the last few years. Getting to a stable system, takes a lot of vendor testing by the likes of Suse, Redhat, etc.
Lastly, the tainted concept works fine for the kernel developers, why not carry it forwared so that any binary driver simply marks the kernel as having a binary module loaded, and uses the standard abstract interfaces instead of linking against all kinds of unneeded kernel crap that just provides the posibility to screw something up.
The smaller mp3 players don't have 60G hd's in them. They have flash, same as the treo. With 1 and now 2GB SD cards are becomming common, so its not like treo's don't have storage capacity. When it comes to battery life, its not cut and dry. The HD based mp3 players have to spin a harddrive, which consumes massive amounts of power spinning up and during the read/seek cycles. That is compared to the amount of power required to passivivly _recieve_ data. Of course transmission is required to make requests and send ACK's but the vast majority of the wireless connection to recieve mp'3 is downstream to the device, which requires little in the way of transmittion power. I have friends who stream mp3's on their treo's (and get cut off for it, unlimited doesn't always mean unlimited apparently). Apparently some of the players work with larger chunks of data. That way the wireless connection is only open for a short period of time to transfer the data then it sits buffered in the memory for an extended period of time waiting for playback.
Over time the bandwidth on these devices will get better as people want to do more and more on them, so I expect that will also improve. The only real limiting factor is the battery life, but I don't expect there is going to be a huge advantage carrying around a harddrive, in terms of battery life.
Wow!!!!! Please provide a link to where I can get a Treo 650 with a 60GB hard drive. I thought the Treo was just a PHONE with only 23 MB of available flash memory. Obviously I don't know shit, and need to get this miracle device.
I think treo type devices are the future. It doesn't need a 60GB hd because it has internet access to your home machine with a 500GB harddrive, and realtime access to sites with far more storage than you will ever be able to carry around in your back pocket.
Well, I use emacs at work, but I don't really like it. I've used VI a lot too. The diffrence is that emacs can be used as a real programmers editor (by definition a programmers editor needs a built in scripting language). I can make it do anything I can imagine and then bind those things to any key I want. In VI I end up writting lots of bash/perl/awk/etc scripts, and shelling out to perform some task. Plus the vi key bindings drive me crazy. I expect certain keys to behave certain ways. In emacs I just remap them to do what I think they should do.
In truth, As I pointed out in an erlier post, emacs lost a lot of its following to the IDE crowd. People who wanted a programmers editor discovered that editors tailor made for particular languages with built in utilities and real syntatic parsing were easier to use. Especially when they are bound to GUI toolkits like Borland C++ and Netbeans. Emacs was a general purpose editing enviroment that takes a bit of pain to setup as a programmers editor but is functional. The IDE's just tend to work, and the good ones have macro languages, and key rebinding just like emacs. I still run GDB from emacs, but the integration isn't nearly as nice as visual studio and its debugger, even with my hacks. With an IDE the fact that your editing or debugging your code is transparent. Given the choice I would bail from emacs and use a real IDE. Given my mostly unix enviroment (all the major unix's with some driver development mixed in), things like kdevelop still doesn't work for me. So I have emacs, and probably will, until I start doing more regular windows programming again, in which case I will use the IDE that comes with whatever development enviroment I'm using.
Oh, and I will continue to show off to vi users when they come in my office by doing fancy reformats and moving around our CVS repository like file boudaries and diffrent cvs versions don't exist. I know enough about vi to know what it can't do and its not hard to find things that are easier in emacs. My .emacs file will also continue to grow as I add cool new things I think up each day while programming my fingers off enough to produce more code than all our vi users here put together.
Those work too, just like in vi. I do have about 30 lines of rebound keys in my .emacs file. I don't know any serious emacs user that doesn't. I like being able to do remote builds on the development server with my editor and other simple things with 1 keystroke. I have rebound the 'delete', 'home', 'end' etc keys behave as I would expect but that took all of 30 seconds to do.
This is emacs primary problem, the type of people who used to use emacs have all moved on to fully integrated IDE's. The people who don't know a programmers editor from a text editor continue to use VI.
Google for "emacs PHP mode". I have one that I use, I can post if you can't find a good one.
You see this because you are a graphical editing "expert". People who are experts in other areas have similar problems with other opensource projects
For example the linux kernel/standard libraries are like this. It works from a perspective where it pieces of functionality needed by a large group of users are there, but when you _NEED_ functionality not covered by posix (or some proprietary linux solution) your sort of left in the dark. My current problem, is how to get the WWN from a fiberchannel adapter in linux. Its basically impossible, but its really easy in windows. Even basic OS services like async IO and control over the OS caching behaviors is non existant. The fsync() system call in linux is still broken from the perspective that its only suppost to flush the file's buffer, not the whole cache.
The list goes on, a lot of people are suckered into the myth pervalent on /. that opensource solutions can replace any commercial one. I think this myth is pervalent because the people pushing it are mostly high school and recent college graduates who are mostly clueless about state of the art commercial programs. After a few years of work they are no longer on /. because they have grown up and are two busy doing real work and having a life to waste time correcting the falsehoods common here and on similar sites.
How about a cheaper solution... A pair of earplugs, then wear the headphones over the top.
.NET assholes. I've been running the 64-bit version of windows for a year (2?) or so now. I got it basically the day the early beta came out. Back then the only way to build 64-bit applications for windows was to run 6 and use the DDK compiler with it.
.net versions anyway, so I'm still running 6 with the newer compilers underneth. It feels a lot faster and the keymappings work the way my fingers expect them to. I tried 2005 for a while but couldn't figure out how to get it to behave like 6. A lot of it has to do with the fact that I run the with the screen nearly full of source files, and use the alt-number shortcuts to pop up the errors, and project management windows. This doesn't work in 2005 which is really anoying.
I never really liked the
Apple's crude discontinuation of Lisa was just the first in a series of major customer mis-steps by Apple.
Your point is taken, but your are forgetting the Apple II. A computer that kept apple in buisness until the mid '80's when the mac finally started to make money. All during this time apple continued to sell II's into a _LARGE_ market that wanted an updated machine. If instead of focusing on making a new computer they had simply improved the apple II we would all be running 6502 clones instead of x86 clones. Originally apple said the II was a dead end because its processor was only 8 bit, and a bunch of other reasons, which were all proven wrong, when apple released the IIgs. A number or 3rd party vendors that made harddrives, faster CPU's, ram expansion cards etc also proved that apple was just being stupid. I was one of the people who held out for a faster II until I bought a x86 machine.
Hmmp, sounds like your stretching it. Your original post is quite misleading (maybe on purpose). Your second point about sql server and "enterprise" usage would lead someone to believe your talking about a "server" environment. Where you "again" claim to have the same memory limit. Which is about as misleading as is possible? In which case my post was completely valid.
Are you a politician, or a "geek"?
Ah, how the mac people forget rhapsody
http://toastytech.com/guis/rhap.html
Which I know runs on x86 because I have a copy.
More clueless crap, for Unix to really be the future, it needs to get rid of its legacy bagage and truely become "well understood". Frankly a lot of people think they understand unix because they are stuck in a single process/text based enviroment mindset. In reality the "extensions" made to unix to support current programming models are full of holes.
When RAS, threads, async io, multiple processors, and may other things that really are the "future" (or rather the current state of the art) are well understood by the unix community they will understand what needs to be changed in the model from the 1970's the people claim is Unix. When that happens unix will be the future, but it won't be "Unix" as you know it.
Now for some more concrete examples. Lets start with a simple one. What does the system call "close()" do? Thats right, did you know it can fail? Whats the solution? Try again. Now think about what happens in a multithreaded enviroment with open() happening in other threads. I can't find a link to Linus's comments on this but they are ammusing. The bottom line is that in a threaded POSIX enviroment you have to write code that looks like (in psudo code to remove the specifics):
app_open(filename,...)
{
lockmutex(globalopenlock)
rc=open(filename,...)
unlockmutex(globalopenlock)
return rc
}
app_close(filehandle)
{
lockmutex(globalopenlock)
while (close(filehandle)!=EBADF);
unlockmutex(globalopenlock)
}
If such a simple unix concept as open/close is screwed up by threads, just imagine what happens when you write code to trap percise floating point exceptions, deal with async filesystem IO over an unreliable network, the list goes on. Basically unix is good for certain kinds of applications and absolutly blows chunks for other kinds. Everyone doing a lot of these things has tied themselves to a particular Unix implementation and uses system specific knowledge to solve the problem.