Clever engineers know that 95% of their code is not performance critical at all (i.e. cpu idling most of the time), and that it makes a hell of a lot of sense to do whatever is necessary to get that 5% performing as best as possible if the cost in terms of stability, productivity, security, portability, etc is low enough. That's why server-side c is not a commonly required job skill.
Server side, web development isn't done in C because the bottlenecks are almost always the database (which is written in C) and the IO bandwidth of the internet connection. That combined with the fact they are almost always custom, single company jobs. Given that there are a number of languages designed initially for web development. That they are better at it than C shouldn't surprise anyone.
You can be assured that just about every other kind of "server" IS written in C. The project I work on is handing more than 5GB (bytes!) of IO data a second per machine (fairly standard X86 hardware). That kind of IO throughput is simply not possible with most other languages. You don't see samba written in java for reasons similar to our project. The low level optimizations required to make it run fast just don't exist. Its also heavily dependent on the economies of scale. If your application runs on four servers at two sites, then there really isn't a reason to optimize it to run on a single server at each site. On the other hand if your application runs on two servers per site at 10k sites, then its a significant cost savings when you make it handle the same load on a single server.
I semi-agree -- procedural languages are much closer to the way most people think, and that's why pure functional languages have remained a niche.
The way people think is one thing (they can be trained), the problem is that CPU's are linear execution machines. That's the difference between a CPU and a custom piece of logic in VHDL. SMP added parallelism but its _INDEPENDENT_ execution. Anytime those contexts interact they need to be synchronized. Determining the synchronization requirements from a compiler is HARD.
Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.
Except that auto detecting and synchronizing generic (I'm not talking about vectorization) parallelism is a hard problem. If you look at the thread ring benchmark you will see that haskell and erlang post significantly better results than C. A closer look shows that the C routine is balancing the CPU usage, while the haskell/erlang results are running entirely on a single CPU. How is it a micro benchmark like that could run 20x as fast in haskell on a single CPU as the C version does using all 4 CPU's? Its because C is explicitly context switching, while the haskell implementation is implicitly using a cooperative threads model. Doing that would be extremely easy in C, but its disallowed. It is possible to write massively parallel code using something like VHDL, the problem is that the locking is still explicit (via clocking) and the result is extremely slow. Frankly, if someone could actually write a compiler that does SMP parallelism on procedural code, without doing a time/space tradeoff, or a number of other fundamental issues, there name would appear in every comp sci book for the rest of history.
Harbor Freight vs Snap-On tools is a good case study. At Harbor Freight, you can equip a mechanic's toolbox for about 5 to 10% of the price of the same tools from Snap-On. Sure, the tools are crap, but almost all of them will work at least the first time you use them, and usually they'll last about 5 to 10% as long as the Snap-On tools.
For the shade tree mechanic, lasting 10% as long as the quality tool, is still far longer than necessary. In other words I'm only using that drill for a couple hours a year instead of on a daily basis. The cheap Chinese junk is fantastic when you need some special tool to avoid having to call the "expert" to come out and charge you $1000 for a hours work. When your done you just throw the tool away. Frankly, in my opinion its a sign of how imbalanced the economy is.
That said, the problem with a lot of the HF tools is that they are simply junk, they sell machine tools that have so much play in them its impossible to produce anything but rough cuts. Their welders are incapable of maintaining any kind of reasonable duty cycle, etc.
By the way, don't reply with any "you get what you pay for" cliche's, by stroke of fate, I have been given two $3K notebook PCs in the past 3 years (MacBook Pro and Sony Vaio), the first has a bad heat-sink on the GPU
This has been true for a long time, and is one of the reasons I run windows on my machine. Using windows its pretty rare for me to think "how come no one else has seen this problem". My problems are rarer, and generally when i'm having one a quick google search turns up a solution. With other OS's (big UNIX's as well as linux). I'm always sitting around thinking "how did this get out of test, its completely broken, as I wait months for a vendor patch" which finally arrives and makes everything works as expected. I used to tell people I was cursed because the weirdest things would happen to me, then I realized it was because I was an unusual customer always checking out that cool new feature or buying some rare product. Now, I just buy junk unless its something I expect to use for a while, in those cases I also consider how long its been on the market or if what I'm doing is common.
I restored a Southwest Technical Products machine back in 1998 that is still running. That's from 1975 and is my oldest machine. I also have an Apple ][+ (1977) with a ProFile hard drive that I recently got working. That is from around 1981. Mine is a 5M version. I don't know the exact manufacturing date on the HD, I suspect that it was closer to 1983. I also have an old acoustic coupled modem. It doesn't work, but I will probably fix it at some point. My oldest PC is an old XT clone with a real 8086, from the late 80's.
I'm 6'7" and I've done extensive "research" in the past on leg/headroom in cars/trucks. Your right the size of the vehicle has absolutely nothing to do with passenger headroom. Its very frustrating, these huge trucks/SUV's usually have less headroom/legroom than little cars like the toyota matrix. Its because they raise the seats 2 1/2' off the floor so the idiots driving them can see over the hood. Then it costs $1 more to add the ability to raise/lower the seat more than 2". Speaking of which i'm guessing about 95% of the cars on the road are within 3" of each other for headroom. Then there is the problem of reaching the steering wheel. Some cars have >12" of seat travel, but the steering wheel telescopes less than 2". WTF? Why go to the cost of a telescoping steering when it moves 1"?
Thank god for the web, because most of the manufactures put the interior dimensions online, so you don't have to pray the dealer has the information and spend days traveling around to dealers collecting it. Instead you can spend a few hours poking around web sites with a spreadsheet and get a fairly good picture.
Because strncpy() is as bad as strcpy(). The problem lies in the fact that if the source string is longer than the destination len, then strncpy simply stops the copy without writing a NULL. The next str* function used on the string is likely to crash.
Most of these comments make me want to puke. I've worked on everything from OS and drive code to firmware/bios code. The one thing I've learned is that you _DONT_ want a heavyweight BIOS/firmware. There is a certain appeal to having a system which ships with a hypervisor, and a heavyweight BIOS that can do everything from configure your memory subsystem to allow remote web based console visualization. On the other hand, you have massively complicated and restricted your system. Everyone thinks that putting all this functionality on the motherboard is a good idea because you only have to flash your BIOS once in a while.
If you want an example of where a heavyweight BIOS leads to, you only have to look at the EFI or OpenFirmware specification. They are so full of technical holes and complexity that nothing works right, and in the case of EFI you have to update the drivers in the BIOS as often as you have to update them in your OS. So, instead of one driver you have two.. Plus flashing cards, or upgrading firmware drivers is _NEVER_ as easy as installing a new OS driver. There is always some technical or human factor that kicks you in the rear.
I've had this discussion with other people in the field, and basically aside from the zealots a lot of other people agree. The core concept of the PC BIOS is really close to the ultimate design. Of course its 25 years old, so its gained a lot of cruft and bugs, but if you were to start over the goal should be a modern version of the BIOS rather than some embedded OS, hypervisor, etc.
What you want is fairly lightweight bootstrap and POST utility to get the machine far enough along that you can fetch the hypervisor, or OS from the disk. This means you have to standardize the API for functions like read sector, print text on screen, read data from keyboard etc. You also have to provide the ability to extend or override those functions from a firmware blob sitting on a SAS adapter, or video card.
This is not an argument against service processors (an entirely separate topic, that people often get confused about), but rather an argument that I don't want my motherboard to try to standardize a hypervisor or OS. I want that decision left up to me. Generally the poor dumb customer doesn't want it either, they just want a machine that runs windows, linux, OSX or whatever, if they are even that detailed. The OS in the firmware people forget that firefox has been sending me weekly (daily?) patches lately, and its likely that over a few years timeframe the later versions of FF won't even run on some older firmware restricted OS without the original vendor providing upgrades. This puts the motherboard vendor in the position of being the support infrastructure for the _WHOLE_ computer. Something i'm sure the majority of them are unable to provide, even though they may have a couple people who can port corebios/linux/etc to run on their hardware.
I don't think there is anything wrong with it, but when it starts to fill up it does get more cumbersome.... For the first little bit I wasn't all that impressed with ribbons, after a few months I dreaded having to use the laptop with Office 2003
This is simple human behavior, you bang away with something long enough you get used to it, everything else is foreign. Doesn't really matter how crummy it is. Ksh/Bash is the perfect example. Great for lots of things, painful to learn, impossible for grandma to use. Yet, lots of computer people thing its the ultimate UI.
That said, having a poorly thought out menu bar doesn't mean there is something wrong with the concept. This is the fundamental problem with office 03 (and many other apps). What happens is the initial menu layout, button layout and context menus are "designed". Then for a decade every time a new feature gets added, it just gets slammed into a random location in the menu bar. Menu bars don't get any more "full" than the ribbon does. The ribbon bar is little more than a prettier button bar. There isn't any reason why the two could not exist in the same application. Use each for their strong points.
Sometimes applications try to clean up their menus, but everyone always complains how feature x went from place y to place z. Generally this is a sign the cleanup was a failure. Most of those failures are caused because no one spent the time to actually re factor/fix the related dialog boxes to group similar actions in a logical manner. I'm sure that if the Office people had spent 1/2 the time cleaning up the menu/button/context menu interface in office they spent on the ribbon the resulting product would have been a shining example of good UI design.
Internally, I'm sure this is a political thing. The guy who slaves over the UI layout to make it consistent across applications isn't going to get the spotlight as much as the guy who completely rewrites the UI throwing out everything right with the old one, along with its warts. Generally when this happens you simply shift the problems, rather than actually solving anything. This seems as apparent with office as the hundreds of open source projects that reinvent the wheel rather than fix the old buggy one. The ribbon has advantages, but its also got some serious problems. Read the complaints, many are fundamentally unfixable, but since they are "edge" cases no one cares.
In the end my opinion this change was entirely superfluous, and poorly thought out. If they really cared about their customers they would have cleaned up the menu and made it functionally similar to the ribbon, then provided a toggle to switch between the two interfaces. Then they would have released it and collected some data on how their users were actually using the program. If it turned out that the majority were using the new ribbon, then they could have removed it in the next version of office. What they did, looks like cowboy design and coding at its worst.
My wife just had a baby and I had a discussion about the hospitals electronic records system with a nurse there. While it sounds like a great idea, and saves them a bunch of time in some cases. The hospitals system sounds really buggy, and its secured to the point where bugs which would normally just be annoying turn out to be 1/2 hour long calls to help desk/security to reset machines/user id's.
None of this is a surprise to anyone familiar with the services provided by IBM or similar companies. What gets me is the amount of money being spent on dozens of system which in the end are just going to be a mismatch of partially communicating systems. There are only about a half dozen "standards" for record exchange. None of which are complete enough to actually build a system. Its like the SNMP protocol. It gives you warm fuzzies, but completely useless without standard MIB's for device classes.
So, you have the government spending $19B and its not really going to do shit. You will see more computers, but if you are out of state and get sick its likely your medical history still isn't going to be available to the ER doctor treating you. What the government should do, is form an independent foundation and hire a couple systems engineers, nurses etc, to go around and look for example installs of some small companies product which appears to be mostly functional, scalable and has a decent core architecture that supports some kind of application specific plugins and record exchange. Ideally the system has not only a client application, but a standalone web interface, and runs on fairly standard hardware.
The smaller the company/product the better. Then they need to take a few hundred million of the 19B and purchase the company and make that product the standard system available to any hospital or doctors office for free. A reference hardware/software stack should be setup. It should then be documented such that 3rd parties can write plug-ins for their baby monitors, CT scanners, etc. The resulting data from the plug-ins should be represented in a standard way in the system. The government could then setup a couple of server farms to act as information brokers/backup agents for the larger doctors offices or hospitals and provide web interfaces for the smaller doctors offices.
That system could then be the reference system and doctors/hospitals are given the remainder of the 19B to implement local versions of the same software stack. If the office is to small to implement the whole stack they can use the government servers over a secure connection. Even accounting for massive waste and corruption, with ~300k doctors in the US, 19B works out to 63K each, which should be more than enough to provide and maintain the system for a couple of years. The cost savings from having a single reference implementation should be huge, compared with the current method of giveaways to big IT companies for what is 30 year old records management technology.
I suspect that TW is backing off because its becoming a political issue here in Austin. The mayoral election is in a couple of weeks and during the recent "debate" it was an issue with all the involved parties coming out against it. Austin has a lot of geeks, and artsy types who are politically active. That combined with the fact that the state legislatures are all in town means there were a lot of constituents showing up at the capital demanding an audience. Pretty much everyone was agreeing that we needed more competition in the ISP market and a number of solutions to create it were floating around. TW realized that they were risking tipping over their very sweet little monopoly just to squeeze out a little more cash. Next time they will pick a more politically opportune time to bring it back.
Yes, that's what I want. A combination of an ineffective, bitter company and a government agency managing my internet connection. That could only improve our service, right?
Can it really be any worse? Christ, TW canned their usenet servers! Deregulation was a popular argument phrased in exactly the same way. The problem is that infrastructure services (roads, water, sewer, electric, phone, ISP) are fundamentally monopolies. Monopolies don't provide good services or quality products. Regulation is there in an attempt to encourage efficiency rather than cost gouging. Besides the banking mess, look at what electric "deregulation" has done. I am an Austin energy customer (city owned utility), at this point they are close to the cheapest rates in Texas, even though they are spending money left an right on all kinds of expensive green projects (energy efficiency rebates covering just about everything, insulation, lights, appliances, solar panels, etc) like solar farms, wind power etc. A study came out last year showing the relative energy price changes in Texas vs other deregulated markets and the rest of the country. Anybody with a brain has to be convinced it is a huge failure.
Just as the energy regulations models work fairly well, i'm sure we could regulate the cable/telco/ISP's in a manner which provides competition, plenty of capital to build infrastructure and manages to keep us competitive with the rest of the world.
Give me a break, the quality of capacitors, and the push for ROHS (see http://www.google.com/search?hl=en&rls=com.microsoft%3Aen-us&q=tin+whiskers+ROHS&btnG=Search) among other things has definitely put an age limit on most modern hardware. I have machines from the 70's that still run and 486's from the mid 90's that run continuously (firewalls). But strangely enough, my more recently machines rarely last more than 5 years.
With the current price of machines, and their apparent disposablity, you probably better off trying to create an environment that isn't dependent on any piece of hardware lasting more than a couple of years. Spending thousands on "quality" hardware isn't any guarantee of lifespan. Your probably better off buying a year or two old model (buy it new, the idea being the bugs are worked out) of a low end business class machine from dell or HP, lenovo, etc.
Then virtualize your environment. That way you can just swap the a dead machine for a working one in the future without having to worry about compatibility.
Then I started trying to play HD content, blury rips, VC-1 coded movies, etc. It has all kinds of problem, from lack of support for some audio codecs, to crashes, garbled video etc.
Then I discovered XBMC, and its become my player of choice. I don't particularly like its interface* but it works fantastically.
*its too media center oriented, it would be great on a media pc, but its not so great as a desktop application.
Uh, you are aware of how fork() worked back in the day, right? When I started using it it didn't even use copy-on-write, the child process shared the same page tables as it's parent.
Well we must have been using different flavors of unix... The old unix systems I used, that predated COW, actually made physical copies of the process. That was _REALLY_ slow. COW was a huge improvement over that. I remember writing lots of code which manually managed shared memory segments between processes in order to implement process memory sharing, which wasn't the default behavior. Now I just spawn a thread and life is much better.
Clone the page tables, flag the pages as COW and you're pretty much there. In fact, as I noted, if you look in for instance Linux fork() and pthread_create() are in fact both simply thin wrappers that call the underlying clone() function.
Uh, on most machines dinking with the page tables is very expensive due to TLB flushing. Later if you actually access any of those COW pages the page faults and physical memory copies are also quite expensive. That is why thread creation is so much faster, it doesn't have to mess with the process address space. Also, if you notice http://linux.die.net/man/2/clone the clone system call has a bunch of flags which control what is "cloned". Depending on what flags you set varies how heavy it is. Linux hasn't exactly done this in the most efficient manner in the past, and hence the performance problems in the past. I haven't benchmarked it recently, but a couple of years ago, linux thread creation was significantly faster than fork() I assume that is still true, I expect that the performance difference has probably gotten even larger.
Unix didn't for a long time have lightweight preemptive threads because it had, from the very beginning, lightweight preemptive processes. I spent a lot of time wondering why Windows programmers were harping on the need for threads to do what I'd been doing for a decade with a simple fork()
LOL, Uh, you are aware that fork() isn't exactly lighweight? In fact its probably the most heavyweight of any process spawning method. Hence the dozen's of modifications to fork (see vfork() for example)on assorted unix's to make it fast. CreateProcess() in comparison is significantly lighter because it doesn't try to carry process context around. Real threading is generally significantly faster on most hardware arches and OS's.
In a real world application, as others have mentioned pretty much all of a programs time is spent in an idle loop waiting something to happen and in almost all circumstances it is input from the user in whatever form, mouse, keyboard, etc.
If by that you mean blocked on the message queue waiting for an event.. Or maybe you were talking about the kernel's idle task putting the CPU to sleep.
No. You write a loop that terminates when close() succeeds.
And you end up with bugs...
Slashdot appears to have eaten my original comment... I posted the applicable posix section in another comment. The bottom line is you have to check for a failure with EBADF as well, as its possible you never get a successful close. This actually happened to me a few years ago on a unix which shall remain nameless while accessing a NFS mounted files. The end result was a piece of code very similar to what my original comment indicated. This is because you may have successfully closed the file, but gotten a failing return, followed by an open reusing the FD (see posix open, "Upon successful completion, the function shall open the file and return a non-negative integer representing the lowest numbered unused file descriptor."). That is why you have to lock it, there isn't any guarantee that the FD wasn't reused between a close that returned a failure, and the next successive call to close.
I believe my original point stands, and is further reinforced by your comment which will probably work in 99% of cases, but deadlock if you get a signal during the close, or the close fails due to some other IO error.
"If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified."
You may successfully close the file and never get a successful return from close.
The problem with using posix for anything is that the specifications are so loose as to be nearly useless. This happened because the specs were written by committees manned by the major UNIX vendors. Those vendors all made sure that the specification covered their implementations ugly edge cases, so they wouldn't have to update anything in their OS.
In the end, Posix is basically useless to write any kind of application code. If every application developer out there tried to deal with every edge case in the Posix specifications they would never get any real code written*.
On the other hand, kernel and OS developers love Posix because they can write just about anything, and it conforms to the specification. They can write all kinds of broken threading implementations, messed up communication and filesystem crap, and it conforms. When something unexpected happens, its the application developers problem because they failed to account for some strange case that doesn't happen in 99% of situations or cannot happen on the platform the application might have originally been written on.
Not only that, but just about any non trivial application ends up writing big chunks of code to deal with huge swaths of platform interactions that aren't covered by posix (or any other standard for example SUS). Everything from playing sounds, configuring a network interface to rewinding a tape.
*Ok, how about an example: Did you know that the close(2) can fail? What does this mean for real applications? Well you have to sit in a loop doing closes on a handle until it returns EBADF. Ok, simple! Now what happens if you have a threaded application where the threads are doing opens/closes? Open and close are marked as thread safe, but because close can fail you need a loop, now what happens if your loop successfully closes a file handle, and another open somewhere else successfully opens and reuses your file handle? That is right, the close loop will close it, leaving you trying to use a file handle that is actually been closed! Whats the solution? Well now you have to write a open/close wrapper that pthread_mutex_locks() a global lock to assure that you aren't getting open/closes running at the same time. This can get worse in some other cases, but i've proven my point. Posix is a rabbit hole.
Well, I personally know that InComm is an authorizer to companies that sell iTunes cards at retail, and that unactivated cards have no value. No algorithm is used for those cards, other than the non-sequential generator (to prevent my_card_number+1 fraud.)
But I also know that TFA claims that an algorithm is broken allowing for virtually unlimited generation of cards.
There are at least two other possibilities. The first, is that the random portion of the card id generator is using a pseudo random number generator where the initial seed and offset were discovered. This makes it a card_number+1 type of hack. The problem with this is that they are selling the "fake" cards with known values.
There is another possibility, which is that there are multiple types of gift cards. The ones you buy at retail are actually activated cards, while there may be a subset, hole or second algorithm used to generated cards with fixed values. I find this possibility likely as the gift cards are often given away in prepackaged merchandise, or as part of another transaction. Aka buy this box of cereal get a free $5 itunes gift card. In that case the numbers would either encode the value, or they would be previously generated and activated. In the latter case it would again be a card+1 type hack, but the value would be known ahead of time. In both of these cases, its possible apple isn't loosing any money because it may be the cereal manufacture (or whatever) loosing money.
Slashdot Mirror
Clever engineers know that 95% of their code is not performance critical at all (i.e. cpu idling most of the time), and that it makes a hell of a lot of sense to do whatever is necessary to get that 5% performing as best as possible if the cost in terms of stability, productivity, security, portability, etc is low enough. That's why server-side c is not a commonly required job skill.
Server side, web development isn't done in C because the bottlenecks are almost always the database (which is written in C) and the IO bandwidth of the internet connection. That combined with the fact they are almost always custom, single company jobs. Given that there are a number of languages designed initially for web development. That they are better at it than C shouldn't surprise anyone.
You can be assured that just about every other kind of "server" IS written in C. The project I work on is handing more than 5GB (bytes!) of IO data a second per machine (fairly standard X86 hardware). That kind of IO throughput is simply not possible with most other languages. You don't see samba written in java for reasons similar to our project. The low level optimizations required to make it run fast just don't exist. Its also heavily dependent on the economies of scale. If your application runs on four servers at two sites, then there really isn't a reason to optimize it to run on a single server at each site. On the other hand if your application runs on two servers per site at 10k sites, then its a significant cost savings when you make it handle the same load on a single server.
I semi-agree -- procedural languages are much closer to the way most people think, and that's why pure functional languages have remained a niche.
The way people think is one thing (they can be trained), the problem is that CPU's are linear execution machines. That's the difference between a CPU and a custom piece of logic in VHDL. SMP added parallelism but its _INDEPENDENT_ execution. Anytime those contexts interact they need to be synchronized. Determining the synchronization requirements from a compiler is HARD.
Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.
Except that auto detecting and synchronizing generic (I'm not talking about vectorization) parallelism is a hard problem. If you look at the thread ring benchmark you will see that haskell and erlang post significantly better results than C. A closer look shows that the C routine is balancing the CPU usage, while the haskell/erlang results are running entirely on a single CPU. How is it a micro benchmark like that could run 20x as fast in haskell on a single CPU as the C version does using all 4 CPU's? Its because C is explicitly context switching, while the haskell implementation is implicitly using a cooperative threads model. Doing that would be extremely easy in C, but its disallowed. It is possible to write massively parallel code using something like VHDL, the problem is that the locking is still explicit (via clocking) and the result is extremely slow. Frankly, if someone could actually write a compiler that does SMP parallelism on procedural code, without doing a time/space tradeoff, or a number of other fundamental issues, there name would appear in every comp sci book for the rest of history.
Harbor Freight vs Snap-On tools is a good case study. At Harbor Freight, you can equip a mechanic's toolbox for about 5 to 10% of the price of the same tools from Snap-On. Sure, the tools are crap, but almost all of them will work at least the first time you use them, and usually they'll last about 5 to 10% as long as the Snap-On tools.
For the shade tree mechanic, lasting 10% as long as the quality tool, is still far longer than necessary. In other words I'm only using that drill for a couple hours a year instead of on a daily basis. The cheap Chinese junk is fantastic when you need some special tool to avoid having to call the "expert" to come out and charge you $1000 for a hours work. When your done you just throw the tool away. Frankly, in my opinion its a sign of how imbalanced the economy is.
That said, the problem with a lot of the HF tools is that they are simply junk, they sell machine tools that have so much play in them its impossible to produce anything but rough cuts. Their welders are incapable of maintaining any kind of reasonable duty cycle, etc.
By the way, don't reply with any "you get what you pay for" cliche's, by stroke of fate, I have been given two $3K notebook PCs in the past 3 years (MacBook Pro and Sony Vaio), the first has a bad heat-sink on the GPU
This has been true for a long time, and is one of the reasons I run windows on my machine. Using windows its pretty rare for me to think "how come no one else has seen this problem". My problems are rarer, and generally when i'm having one a quick google search turns up a solution. With other OS's (big UNIX's as well as linux). I'm always sitting around thinking "how did this get out of test, its completely broken, as I wait months for a vendor patch" which finally arrives and makes everything works as expected. I used to tell people I was cursed because the weirdest things would happen to me, then I realized it was because I was an unusual customer always checking out that cool new feature or buying some rare product. Now, I just buy junk unless its something I expect to use for a while, in those cases I also consider how long its been on the market or if what I'm doing is common.
I restored a Southwest Technical Products machine back in 1998 that is still running. That's from 1975 and is my oldest machine. I also have an Apple ][+ (1977) with a ProFile hard drive that I recently got working. That is from around 1981. Mine is a 5M version. I don't know the exact manufacturing date on the HD, I suspect that it was closer to 1983. I also have an old acoustic coupled modem. It doesn't work, but I will probably fix it at some point. My oldest PC is an old XT clone with a real 8086, from the late 80's.
I'm 6'7" and I've done extensive "research" in the past on leg/headroom in cars/trucks. Your right the size of the vehicle has absolutely nothing to do with passenger headroom. Its very frustrating, these huge trucks/SUV's usually have less headroom/legroom than little cars like the toyota matrix. Its because they raise the seats 2 1/2' off the floor so the idiots driving them can see over the hood. Then it costs $1 more to add the ability to raise/lower the seat more than 2". Speaking of which i'm guessing about 95% of the cars on the road are within 3" of each other for headroom. Then there is the problem of reaching the steering wheel. Some cars have >12" of seat travel, but the steering wheel telescopes less than 2". WTF? Why go to the cost of a telescoping steering when it moves 1"?
Thank god for the web, because most of the manufactures put the interior dimensions online, so you don't have to pray the dealer has the information and spend days traveling around to dealers collecting it. Instead you can spend a few hours poking around web sites with a spreadsheet and get a fairly good picture.
So why is strncpy in the banned function list?
Because strncpy() is as bad as strcpy(). The problem lies in the fact that if the source string is longer than the destination len, then strncpy simply stops the copy without writing a NULL. The next str* function used on the string is likely to crash.
Most of these comments make me want to puke. I've worked on everything from OS and drive code to firmware/bios code. The one thing I've learned is that you _DONT_ want a heavyweight BIOS/firmware. There is a certain appeal to having a system which ships with a hypervisor, and a heavyweight BIOS that can do everything from configure your memory subsystem to allow remote web based console visualization. On the other hand, you have massively complicated and restricted your system. Everyone thinks that putting all this functionality on the motherboard is a good idea because you only have to flash your BIOS once in a while.
If you want an example of where a heavyweight BIOS leads to, you only have to look at the EFI or OpenFirmware specification. They are so full of technical holes and complexity that nothing works right, and in the case of EFI you have to update the drivers in the BIOS as often as you have to update them in your OS. So, instead of one driver you have two.. Plus flashing cards, or upgrading firmware drivers is _NEVER_ as easy as installing a new OS driver. There is always some technical or human factor that kicks you in the rear.
I've had this discussion with other people in the field, and basically aside from the zealots a lot of other people agree. The core concept of the PC BIOS is really close to the ultimate design. Of course its 25 years old, so its gained a lot of cruft and bugs, but if you were to start over the goal should be a modern version of the BIOS rather than some embedded OS, hypervisor, etc.
What you want is fairly lightweight bootstrap and POST utility to get the machine far enough along that you can fetch the hypervisor, or OS from the disk. This means you have to standardize the API for functions like read sector, print text on screen, read data from keyboard etc. You also have to provide the ability to extend or override those functions from a firmware blob sitting on a SAS adapter, or video card.
This is not an argument against service processors (an entirely separate topic, that people often get confused about), but rather an argument that I don't want my motherboard to try to standardize a hypervisor or OS. I want that decision left up to me. Generally the poor dumb customer doesn't want it either, they just want a machine that runs windows, linux, OSX or whatever, if they are even that detailed. The OS in the firmware people forget that firefox has been sending me weekly (daily?) patches lately, and its likely that over a few years timeframe the later versions of FF won't even run on some older firmware restricted OS without the original vendor providing upgrades. This puts the motherboard vendor in the position of being the support infrastructure for the _WHOLE_ computer. Something i'm sure the majority of them are unable to provide, even though they may have a couple people who can port corebios/linux/etc to run on their hardware.
#define memcpy(a,b,c) memcpy_s(a,b,c,c)
Chuckle....
I don't think there is anything wrong with it, but when it starts to fill up it does get more cumbersome. ...
For the first little bit I wasn't all that impressed with ribbons, after a few months I dreaded having to use the laptop with Office 2003
This is simple human behavior, you bang away with something long enough you get used to it, everything else is foreign. Doesn't really matter how crummy it is. Ksh/Bash is the perfect example. Great for lots of things, painful to learn, impossible for grandma to use. Yet, lots of computer people thing its the ultimate UI.
That said, having a poorly thought out menu bar doesn't mean there is something wrong with the concept. This is the fundamental problem with office 03 (and many other apps). What happens is the initial menu layout, button layout and context menus are "designed". Then for a decade every time a new feature gets added, it just gets slammed into a random location in the menu bar. Menu bars don't get any more "full" than the ribbon does. The ribbon bar is little more than a prettier button bar. There isn't any reason why the two could not exist in the same application. Use each for their strong points.
Sometimes applications try to clean up their menus, but everyone always complains how feature x went from place y to place z. Generally this is a sign the cleanup was a failure. Most of those failures are caused because no one spent the time to actually re factor/fix the related dialog boxes to group similar actions in a logical manner. I'm sure that if the Office people had spent 1/2 the time cleaning up the menu/button/context menu interface in office they spent on the ribbon the resulting product would have been a shining example of good UI design.
Internally, I'm sure this is a political thing. The guy who slaves over the UI layout to make it consistent across applications isn't going to get the spotlight as much as the guy who completely rewrites the UI throwing out everything right with the old one, along with its warts. Generally when this happens you simply shift the problems, rather than actually solving anything. This seems as apparent with office as the hundreds of open source projects that reinvent the wheel rather than fix the old buggy one. The ribbon has advantages, but its also got some serious problems. Read the complaints, many are fundamentally unfixable, but since they are "edge" cases no one cares.
In the end my opinion this change was entirely superfluous, and poorly thought out. If they really cared about their customers they would have cleaned up the menu and made it functionally similar to the ribbon, then provided a toggle to switch between the two interfaces. Then they would have released it and collected some data on how their users were actually using the program. If it turned out that the majority were using the new ribbon, then they could have removed it in the next version of office. What they did, looks like cowboy design and coding at its worst.
And that's exactly what Sun's Niagara processors are: 8 cores running 4 threads apiece, and fast at integer math.
That would be great for sun oracle except for one problematic fact. They don't compare favorably to stock x86's in the mysql/posgresql benchmarks.
My wife just had a baby and I had a discussion about the hospitals electronic records system with a nurse there. While it sounds like a great idea, and saves them a bunch of time in some cases. The hospitals system sounds really buggy, and its secured to the point where bugs which would normally just be annoying turn out to be 1/2 hour long calls to help desk/security to reset machines/user id's.
None of this is a surprise to anyone familiar with the services provided by IBM or similar companies. What gets me is the amount of money being spent on dozens of system which in the end are just going to be a mismatch of partially communicating systems. There are only about a half dozen "standards" for record exchange. None of which are complete enough to actually build a system. Its like the SNMP protocol. It gives you warm fuzzies, but completely useless without standard MIB's for device classes.
So, you have the government spending $19B and its not really going to do shit. You will see more computers, but if you are out of state and get sick its likely your medical history still isn't going to be available to the ER doctor treating you. What the government should do, is form an independent foundation and hire a couple systems engineers, nurses etc, to go around and look for example installs of some small companies product which appears to be mostly functional, scalable and has a decent core architecture that supports some kind of application specific plugins and record exchange. Ideally the system has not only a client application, but a standalone web interface, and runs on fairly standard hardware.
The smaller the company/product the better. Then they need to take a few hundred million of the 19B and purchase the company and make that product the standard system available to any hospital or doctors office for free. A reference hardware/software stack should be setup. It should then be documented such that 3rd parties can write plug-ins for their baby monitors, CT scanners, etc. The resulting data from the plug-ins should be represented in a standard way in the system. The government could then setup a couple of server farms to act as information brokers/backup agents for the larger doctors offices or hospitals and provide web interfaces for the smaller doctors offices.
That system could then be the reference system and doctors/hospitals are given the remainder of the 19B to implement local versions of the same software stack. If the office is to small to implement the whole stack they can use the government servers over a secure connection. Even accounting for massive waste and corruption, with ~300k doctors in the US, 19B works out to 63K each, which should be more than enough to provide and maintain the system for a couple of years. The cost savings from having a single reference implementation should be huge, compared with the current method of giveaways to big IT companies for what is 30 year old records management technology.
I suspect that TW is backing off because its becoming a political issue here in Austin. The mayoral election is in a couple of weeks and during the recent "debate" it was an issue with all the involved parties coming out against it. Austin has a lot of geeks, and artsy types who are politically active. That combined with the fact that the state legislatures are all in town means there were a lot of constituents showing up at the capital demanding an audience. Pretty much everyone was agreeing that we needed more competition in the ISP market and a number of solutions to create it were floating around. TW realized that they were risking tipping over their very sweet little monopoly just to squeeze out a little more cash. Next time they will pick a more politically opportune time to bring it back.
Yes, that's what I want. A combination of an ineffective, bitter company and a government agency managing my internet connection. That could only improve our service, right?
Can it really be any worse? Christ, TW canned their usenet servers! Deregulation was a popular argument phrased in exactly the same way. The problem is that infrastructure services (roads, water, sewer, electric, phone, ISP) are fundamentally monopolies. Monopolies don't provide good services or quality products. Regulation is there in an attempt to encourage efficiency rather than cost gouging. Besides the banking mess, look at what electric "deregulation" has done. I am an Austin energy customer (city owned utility), at this point they are close to the cheapest rates in Texas, even though they are spending money left an right on all kinds of expensive green projects (energy efficiency rebates covering just about everything, insulation, lights, appliances, solar panels, etc) like solar farms, wind power etc. A study came out last year showing the relative energy price changes in Texas vs other deregulated markets and the rest of the country. Anybody with a brain has to be convinced it is a huge failure.
Just as the energy regulations models work fairly well, i'm sure we could regulate the cable/telco/ISP's in a manner which provides competition, plenty of capital to build infrastructure and manages to keep us competitive with the rest of the world.
Give me a break, the quality of capacitors, and the push for ROHS (see http://www.google.com/search?hl=en&rls=com.microsoft%3Aen-us&q=tin+whiskers+ROHS&btnG=Search) among other things has definitely put an age limit on most modern hardware. I have machines from the 70's that still run and 486's from the mid 90's that run continuously (firewalls). But strangely enough, my more recently machines rarely last more than 5 years.
With the current price of machines, and their apparent disposablity, you probably better off trying to create an environment that isn't dependent on any piece of hardware lasting more than a couple of years. Spending thousands on "quality" hardware isn't any guarantee of lifespan. Your probably better off buying a year or two old model (buy it new, the idea being the bugs are worked out) of a low end business class machine from dell or HP, lenovo, etc.
Then virtualize your environment. That way you can just swap the a dead machine for a working one in the future without having to worry about compatibility.
Then I started trying to play HD content, blury rips, VC-1 coded movies, etc. It has all kinds of problem, from lack of support for some audio codecs, to crashes, garbled video etc.
Then I discovered XBMC, and its become my player of choice. I don't particularly like its interface* but it works fantastically.
*its too media center oriented, it would be great on a media pc, but its not so great as a desktop application.
They should have done this in Austin. I hear there are a bunch of tech savvy customers looking for a new internet provider there...
Uh, you are aware of how fork() worked back in the day, right? When I started using it it didn't even use copy-on-write, the child process shared the same page tables as it's parent.
Well we must have been using different flavors of unix... The old unix systems I used, that predated COW, actually made physical copies of the process. That was _REALLY_ slow. COW was a huge improvement over that. I remember writing lots of code which manually managed shared memory segments between processes in order to implement process memory sharing, which wasn't the default behavior. Now I just spawn a thread and life is much better.
Clone the page tables, flag the pages as COW and you're pretty much there. In fact, as I noted, if you look in for instance Linux fork() and pthread_create() are in fact both simply thin wrappers that call the underlying clone() function.
Uh, on most machines dinking with the page tables is very expensive due to TLB flushing. Later if you actually access any of those COW pages the page faults and physical memory copies are also quite expensive. That is why thread creation is so much faster, it doesn't have to mess with the process address space. Also, if you notice http://linux.die.net/man/2/clone the clone system call has a bunch of flags which control what is "cloned". Depending on what flags you set varies how heavy it is. Linux hasn't exactly done this in the most efficient manner in the past, and hence the performance problems in the past. I haven't benchmarked it recently, but a couple of years ago, linux thread creation was significantly faster than fork() I assume that is still true, I expect that the performance difference has probably gotten even larger.
Unix didn't for a long time have lightweight preemptive threads because it had, from the very beginning, lightweight preemptive processes. I spent a lot of time wondering why Windows programmers were harping on the need for threads to do what I'd been doing for a decade with a simple fork()
LOL, Uh, you are aware that fork() isn't exactly lighweight? In fact its probably the most heavyweight of any process spawning method. Hence the dozen's of modifications to fork (see vfork() for example)on assorted unix's to make it fast. CreateProcess() in comparison is significantly lighter because it doesn't try to carry process context around. Real threading is generally significantly faster on most hardware arches and OS's.
In a real world application, as others have mentioned pretty much all of a programs time is spent in an idle loop waiting something to happen and in almost all circumstances it is input from the user in whatever form, mouse, keyboard, etc.
If by that you mean blocked on the message queue waiting for an event.. Or maybe you were talking about the kernel's idle task putting the CPU to sleep.
No. You write a loop that terminates when close() succeeds.
And you end up with bugs...
Slashdot appears to have eaten my original comment... I posted the applicable posix section in another comment. The bottom line is you have to check for a failure with EBADF as well, as its possible you never get a successful close. This actually happened to me a few years ago on a unix which shall remain nameless while accessing a NFS mounted files. The end result was a piece of code very similar to what my original comment indicated. This is because you may have successfully closed the file, but gotten a failing return, followed by an open reusing the FD (see posix open, "Upon successful completion, the function shall open the file and return a non-negative integer representing the lowest numbered unused file descriptor."). That is why you have to lock it, there isn't any guarantee that the FD wasn't reused between a close that returned a failure, and the next successive call to close.
I believe my original point stands, and is further reinforced by your comment which will probably work in 99% of cases, but deadlock if you get a signal during the close, or the close fails due to some other IO error.
No. You write a loop that terminates when close() succeeds.
BTW:
http://www.opengroup.org/onlinepubs/000095399/functions/close.html
"If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close(), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified."
You may successfully close the file and never get a successful return from close.
The problem with using posix for anything is that the specifications are so loose as to be nearly useless. This happened because the specs were written by committees manned by the major UNIX vendors. Those vendors all made sure that the specification covered their implementations ugly edge cases, so they wouldn't have to update anything in their OS.
In the end, Posix is basically useless to write any kind of application code. If every application developer out there tried to deal with every edge case in the Posix specifications they would never get any real code written*.
On the other hand, kernel and OS developers love Posix because they can write just about anything, and it conforms to the specification. They can write all kinds of broken threading implementations, messed up communication and filesystem crap, and it conforms. When something unexpected happens, its the application developers problem because they failed to account for some strange case that doesn't happen in 99% of situations or cannot happen on the platform the application might have originally been written on.
Not only that, but just about any non trivial application ends up writing big chunks of code to deal with huge swaths of platform interactions that aren't covered by posix (or any other standard for example SUS). Everything from playing sounds, configuring a network interface to rewinding a tape.
*Ok, how about an example: Did you know that the close(2) can fail? What does this mean for real applications? Well you have to sit in a loop doing closes on a handle until it returns EBADF. Ok, simple! Now what happens if you have a threaded application where the threads are doing opens/closes? Open and close are marked as thread safe, but because close can fail you need a loop, now what happens if your loop successfully closes a file handle, and another open somewhere else successfully opens and reuses your file handle? That is right, the close loop will close it, leaving you trying to use a file handle that is actually been closed! Whats the solution? Well now you have to write a open/close wrapper that pthread_mutex_locks() a global lock to assure that you aren't getting open/closes running at the same time. This can get worse in some other cases, but i've proven my point. Posix is a rabbit hole.
Well, I personally know that InComm is an authorizer to companies that sell iTunes cards at retail, and that unactivated cards have no value. No algorithm is used for those cards, other than the non-sequential generator (to prevent my_card_number+1 fraud.)
But I also know that TFA claims that an algorithm is broken allowing for virtually unlimited generation of cards.
There are at least two other possibilities. The first, is that the random portion of the card id generator is using a pseudo random number generator where the initial seed and offset were discovered. This makes it a card_number+1 type of hack. The problem with this is that they are selling the "fake" cards with known values.
There is another possibility, which is that there are multiple types of gift cards. The ones you buy at retail are actually activated cards, while there may be a subset, hole or second algorithm used to generated cards with fixed values. I find this possibility likely as the gift cards are often given away in prepackaged merchandise, or as part of another transaction. Aka buy this box of cereal get a free $5 itunes gift card. In that case the numbers would either encode the value, or they would be previously generated and activated. In the latter case it would again be a card+1 type hack, but the value would be known ahead of time. In both of these cases, its possible apple isn't loosing any money because it may be the cereal manufacture (or whatever) loosing money.
First, you should use relative amounts (e.g., percentage of GDP) verses absolute dollars.
Politics asside, the problem is that all that GDP growth was fake. The financial services sector was making up the majority of the growth.