Dell could simply adjust the Ubuntu PC prices to compensate for the missing bloatware revenue. Of course, they probably would sell even fewer that way. But with Dell's just-in-time supply chain, it really shouldn't matter whether any particular models sell well because there's no inventory buildup or waste to worry about.

As for Dell's claim of reducing complexity... it's a single link on the side of the page! At the risk of sounding cliche, I think it's more reasonable to assume that there is some supplier exclusivity contract in play from Microsoft.

Most owners care about their business, and use cost-cutting to strengthen the business. But publicly-owned companies are not run by the owners. They're run by managers who may or may not have the best interests of the business in mind. It's called the Principal-agent problem. Publicly-owned companies are more easily corrupted because the owners (stockholders) are not the ones tending to the daily matters of the business.

If that was sarcasm and I missed it, I apologize. Either way, the truth is that cost savings do not roll downhill. Any tax savings realized by corporations goes to officer salaries.

Even if management is ethical, they still won't create jobs; without an increase in consumer demand, the ethical thing to do is distribute the savings as dividends.

So far we have mostly managed to ignore the morons calling for the death of PulseAudio, hopefully that will continue as well.

Pulse is new code, not a rewrite of anything. Yes, ESD was a sound server too, but the similarity ends there.

Many of PulseAudio's problems are caused by "iffy" stuff in ALSA drivers, and the ALSA folks are working to fix the bugs Pulse exposes. Many more are caused by distro people making questionable decisions on how to set it up (see Ubuntu/rtkit).

I'm sure glad that PA isn't going anywhere, despite all the uninformed hate flying around.

Budgets are outlined more than one year ahead of time, so that people can actually plan for the future. They aren't usually set in stone, because as circumstances change it may be necessary to adjust them, but that doesn't mean they don't exist, or that changing them won't cause issues for the department. Giving a smaller than expected increase in budget IS a budget cut, because until that moment plans have been made with the higher number in mind: a change to that number will require cuts to payroll, purchasing, operational costs, or any of the other expenses that the program must pay. If you can imagine attempting to operate a business on a budget that you cannot predict more than 12 months in advance, you might just get an idea why it's necessary to make those kinds of assumptions.

Get it?

Oh, and inflation makes each dollar worth a little bit less than it was before. If you have a budget that doesn't go up from one year to the next, it is effectively going down whether the numbers actually say so or not.

Thanks for playing.

You need at least two classes of service.

Extremely clearly written demarcation points agreed to by the highest levels in the organization. If you don't know what a demarc is, find an old (or young?) bell-head and ask them to explain the concept. On an experimental best effort basis, your department / research group / whatever does anything they want using equipment purchased and maintained by non-IT personnel. This ethernet jack and upstream is IT's responsibility and the cable you plug into it and downstream is all yours to do whatever you want.

Also provide full end-to-end service and support to other groups, with clearly written expectations for both sides.

This works pretty well in the fortune 500, not just at schools.

IT groups are usually pretty good at generic "office productivity tools" and usually pretty awful at specialized vertical integration solutions.

``Intelligent design is simple, everything can be explained because a god decided it had to be so. So our eyes work the way they work because god said so and you can't go questioning god. However god is not perfect. Why are some men color-blind while some women can perceive an extra color? Why can't we see ultra-violet? Why is that other animals have 4 or even 5 cones while we got only 3? It doesn't sit well with the ID idea that birds and fish got far better vision then we do."

Just because there exists color-blindness, etc. does not mean God is not perfect. (It is a proper name, like Gates.) And, "fairness" isn't a rationale, stating that birds and fish have better vision. We have better reasoning, and are slightly more articulate. Would you rather see very far, but be an idiot who pecks at the ground, or swoops at prey?

No no, Feynman is crazy and brilliant. Stallman is crazy and sad.

It seems to me that there is an implied comparison between young hackers and CS undergrads. That the two require completely different languages makes this two different questions. The first question that I read is "should young hackers start with the same languages as CS undergrades?" To which I can only answer "maybe." If the hacker is smart enough, has the resources and the desire to learn at a pace like that, and wants to learn the inner details of varying search algos, sure, throw them in the deep end. Scheme, C, assembly, give 'em the tools and let them work. Being a CS graduate student, or worse, is not about programing but research into ways to program for 10 years into the future. So, if that's what they want, let them learn the details they will need later.

If the young hacker-to-be doesn't want that, why throw them into the same muck? Give them a language that does what they want it to do: Processing, Squeek, Pascal, Prolog; Lua, Lisp, Scheme, whatever. If they don't care which search algorithm is best because they plan to use which ever one is built into the libraries they have, there is no overwhelming need to teach that detail. Let them program in ways that are fun to them, and see how different that can be compared to forcing all the young hackers to learn the same way.

Draek made a good point about the Coke recipe disclosure, but I also have an objection to the comparison between the Coke recipe and source code.

When you go out and buy a coke, you are free to modify it and add a lemon, or boil it down, or use it in a baking soda volcano reaction. The same is true for most physical goods, even hardware. You can crack open your laptop to add memory, or add some wires to a Furby mainboard to have it make weird noises. Whatever. (You usually void the warranty with these things, but that is a reasonable thing for a company to require. If I make an instrument out of Furby, I don't expect the company to fix it if it breaks.)

Programs, on the other hand, are distributed as binaries, which are prohibitively difficult to modify. Yes, you can disassemble them if you really want to, but working on disassembled code is like brain surgery on buckets of the constituent elements of the brain. To make it worse, these programs usually come with an end user license agreement that prohibits any modification, not just at the expense of support, but at the expense of your right to use it.

In order to own a program, you must have the source, otherwise you just have a license to use it under the specifications of the creator. Note that commercial programs can be GPL'd, as long as they provide the source along with the binaries on purchase.

I think he's saying that this is just the Coke --> Coke Clear --> Coke Classic trick. And in this case, it was also done by accident.