Network World and/. have both given this story an unnecessarily inflammatory slant. Zemlin's argument is "Maintaining your own fork of Linux for your product or service is an absurdly large amount of work for precious little return - if you let your business put much time into such things when there's no benefit to your business maintaining its own fork; it could simply pass patches upstream and let upstream take on some of the maintenance worries, you're being an idiot".
Arguably, there is some logic to this. Lots of companies sell Linux appliances - either as virtual appliances, pre-loaded on hardware or as embedded systems - make changes to lots of things but never submit patches upstream.
I think I'm starting to see why corporate PR-spun statements are always so bland. There's no way a corporate PR department would let something like that through precisely because of the likelihood of such slanted articles resulting from it.
However, today we have far less isolation than we did in 1350. It was possible for a community to simply close itself off from the world for a period of time.
They didn't do a very good job of it. It's estimated that 30-60% of Europe's population was killed.
And on the rest... sure, should have raised plenty of red flags. Why would a US company ask a Dutch CA for a certificate? Why would an established site need a new or an extra certificate - a wild card (*.google.com) cert to boot? Now I have no idea how a CA certifies that the requester is actually the owner of a certain domain, it certainly failed badly in this case.
Go buy a certificate some time. There are LOTS of CAs out there who will complete the transaction and give you a certificate in seconds. We'd like to believe that such CAs have some sort of process in place that flags up potentially fraudulent requests for human verification, but as this sort of thing demonstrates that's obviously not the case.
The way LDAP authentication is supposed to work is:
1. Client connects to server to find exactly where in the tree the user's information resides (the user's DN). This is not particularly sensitive - it's usually done either anonymously or with an account with very little privileges. 2. Client drops the connection then tries to re-connect using the DN it found out in (1) and the password supplied by the user. 3. If the server responds that the login has succeeded, let the user use the service. If not, refuse.
A number of people have followed the logs on their LDAP servers and established that OS X Lion isn't carrying out step 2 at all. So provided the user ID supplied is valid, the user can log into the computer.
It's important to note that this process is repeated for every process you want to use. Kerberos makes life a little easier (the server supplies a token to say "This user has logged in OK" and that token can be used to authenticate against services that support Kerberos). In any case, the person is logged into the computer but cannot access network resources. Nevertheless, it's an absurd fault that should have been picked up in testing, I have no idea how it could possibly slip the net.
Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it. I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file. Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick.
I have. There is a PAM module that does an LDAP password update. The biggest problem is that there's about a hundred different ways you can configure it, every Linux distribution makes different assumptions about your environment - assumptions which can change between versions - and this almost invariably leads to interoperability problems. Fortunately they all use the same libraries so you can generally dump a known-good set of config files in the appropriate place in/etc and away you go.
Easy solution to that - instead of storing the fuel source in the form of a solid lump, make it some sort of energy-dense liquid. That way the manufacturer differentiates themselves on the basis of how much liquid the vehicle requires to travel a given distance and how much liquid their vehicle can store, and the charging station simply pours liquid into some sort of tank until the tank is full.
I have it on good authority that Acorn sold virtually no model As. Apparently it was possible to upgrade the RAM, so it's likely that any that were built wound up being upgraded before they left the warehouse.
(This authority isn't written, it's someone who worked for Acorn at the time. I believe him, mostly because most software required a model B - the RAM was shared between every component in the system so by the time things like video had been included, there was nothing like 16/32K available to programs).
Did you actually read the list or did you just take a quick glance at it?
The following sentences could cause a filter to trip:
"The external male sexual organs - or gonads - are the penis and the testicles. The testicles are enclosed in a sac of skin called the scrotum". (Virtually any biology work concerning sex would suffer equally - "vagina", "clitoris", "orgasm" and "ejaculate" are all in the list).
"The role of chimney sweep Bert in Mary Poppins was played by actor Dick van Dyke".
"As part of this woordwork project, each item is held in place with a single screw."
While I doubt the filter would block on just a single instance, if you're talking about (for example) actor Dick van Dyke, chances are his name's going to appear in the essay several times.
I've never yet seen a filter which was worth a damn. But I have worked in a school (albeit some years ago) and the consensus of opinion there was very much along the lines of "the filtering may never work properly and we may be stuck with something that on the face of it causes as many problems as it solves - but the sort of problems it causes are likely to cost us a lot less than the sort of problems it solves."
I dunno. If there's one thing the last five years have shown, Apple are quite prepared to take calculated risks. Moving to x86 architecture, the iPhone and the iPad were all calculated risks which could easily have gone horribly wrong.
I've thought for some time that the "you can run it on ancient hardware that Windows doesn't support" is a terrible argument in favour of Linux (and F/OSS in general) for a couple of reasons:
1. Software that needs to care about the hardware (such as the Linux kernel or the Mesa library) is not exempt from this being a fast-moving industry, and updating drivers is not without cost in terms of effort. Effort that could be better spent elsewhere. 2. I think it hurts credibility to say "Support for more hardware than Windows!" (But most of the supported hardware is at least five years old, some of it's twenty years old! If you want to use a chipset that's been out less than a few months, expect pain!).
Say we want to further add some animation support to the video renderer for use on the OSD, that code needs to be written for each of Xshm, Xv, OpenGL, VDPAU, VAAPI, XvMC, and PVR-350 framebuffer output. In addition, that's primarily the work of one single guy.
And people wonder why some F/OSS projects have a slow rate of development.
Take a look at the level of comfort in the average sleeper cabin. Consider the idea of that being your home from home for 10 days with the wife and children.
Loads of Western tourists pay ridiculous tour-company prices to spend five days on the Trans-Siberian railway. Some pay even more exaggerated prices to go between countries by ship instead of flying. There's certainly a market for spending such time in a fairly enclosed space.
Good point. It may be possible to make it work, but I'm still not convinced that it would work being sold as a family holiday.
Ya know, I know how they could guarantee this thing pays for itself in a year. Hogwarts express trains, starting in the US, making their way through this tunnel, picking up passengers along the way and stopping in england.
Nah, wouldn't work. Back of an envelope calculations:
As the crow flies, it's 3244 miles from London to Novosibirsk and 5867 miles from Novosibirsk to San Francisco. (I couldn't find a website that would calculate the most efficient rail route, so I'm doing it this way instead), giving us a total of 9,111 miles.
Of course, trains don't follow the shortest route. They follow the route that makes the most sense based on who wants to get what items to what destination and what geography and politics allows. I wouldn't be at all surprised to see the total distance more like 11-12,000 miles.
Now, a high speed train link might theoretically be capable of, what, 120-150mph? (Assuming good conditions along the whole journey, and a rail infrastructure that can support it. Worn out, old railway lines typically have to be travelled over more slowly). But with the sort of distances involved it'll be necessary to stop to pick up supplies, passengers and swap drivers. I'd be surprised if you averaged much more than 50mph across the entire journey. Your Hogwarts Express journey is going to take upwards of 10 days and will cross a minimum of 8 national borders. (US-Canada, Canada-US, US-Russia, Russia-Belarus, Belarus-Poland, Poland-Germany, Germany-France, France-UK). Doubtless the tour operator would take care of visas, but it's something that would have to be booked some way ahead of time - you couldn't just decide to do it tomorrow.
Take a look at the level of comfort in the average sleeper cabin. Consider the idea of that being your home from home for 10 days with the wife and children. Now, about that Hogwart's Express idea...
They don't really support them - not in the same sense that Apple do with the iPhone. Most of the handset manufacturers are still very much stuck in a 10 or 15 year old mindset where they build the phone, put the software together and as soon as it's in mass production they hardly touch the phone's firmware (except in occasional cases of really heinous bugs, and not always then).
If they were all using MS Office, I'm sure they wouldn't mind paying for it. No, the problem is that they'd have to pay as if everyone was using MS Office, because virtualisation and commercial licensing don't play ball.
Funny, that sounds like exactly the sort of clause that is strictly non-negotiable until you're a big enough organisation and you inform the press that you're moving the lot over to a F/OSS alternative.
Non Apple Tables are priced roughly $200-300 too expensive. Get them around $199-$299 and they'll sell like gangbusters just like it did for Android phones in the mobile market.
The thing is, nobody's done that yet. Considering the speed at which this industry normally moves, I have a sneaking suspicion that nobody's succeeded in making a tablet that they can sell for $2-300 and make a profit on.
I can tell that for Greece, part of the EU with the 2-year mandatory warranties, Apple DOES NOT give you a second year. Yes, it is illegal, yes people have managed to fix their products by taking them to court, yes Apple products are more expensive here anyway. And yes, I am sure Apple is betting on fan loyalty to get away with this.
Few technology companies willingly give a two year warranty; you usually have to take them to court to enforce it. Apple is hardly alone here, it's pretty obvious that the majority of companies have decided that most consumers are totally unaware of their rights and have decided it's cheaper to pay for the few that are aware and hope everyone else buys a new item after 18 months than it is to openly announce an extension to their warranty programme.
It'd be nice if the various Trading Standards bodies in Europe were to do something about it, but you don't get something for nothing. I suspect if that were to happen, we'd see some fairly significant price restructuring within a couple of months.
It's unlikely you'll get external storage - Freeview in the UK started encrypting the EPG a few months ago; the only way to get decryption keys to put in your STB is if you agree to make it difficult for people to get recorded programs off the box. I can't see Virgin Media's agreements with the TV companies being dramatically different.
I think a lot of people don't realise how big Foxconn is. They have factories the size of a reasonable town; you will see all sorts of things in an organisation that size - births, marriages, deaths, the lot - and suicide will be part of it. If you were to talk about Foxconn as a town and say "this town has a quarter the suicide rate of any other town in China", it'd be fantastic. But because we talk about it as a company, it sounds terrible.
Not really. In general terms, printing consists of:
1. Application generates printout in some sort of language that is suitable for describing printed images. 2. OS converts the printout into something the printer can understand. 3. OS sends the result to the printer.
Under more-or-less any Unix, the language used in (1) is Postscript (though IIRC it's PDF in OS X - which is easy enough to translate to Postscript).
So if you use a Postscript printer, the amount of work required in (2) is very little - and for all practical purposes can be said to be driverless. Doesn't work so well for inkjet printers, however, which seldom have the intelligence to handle Postscript.
More and more of them these days - wireless networking is rapidly becoming the norm in even cheapie consumer inkjets. Apple aren't thinking about the printer you buy today, they're thinking about the printer you might buy in 2-3 years time.
Slashdot Mirror
Network World and /. have both given this story an unnecessarily inflammatory slant. Zemlin's argument is "Maintaining your own fork of Linux for your product or service is an absurdly large amount of work for precious little return - if you let your business put much time into such things when there's no benefit to your business maintaining its own fork; it could simply pass patches upstream and let upstream take on some of the maintenance worries, you're being an idiot".
Arguably, there is some logic to this. Lots of companies sell Linux appliances - either as virtual appliances, pre-loaded on hardware or as embedded systems - make changes to lots of things but never submit patches upstream.
I think I'm starting to see why corporate PR-spun statements are always so bland. There's no way a corporate PR department would let something like that through precisely because of the likelihood of such slanted articles resulting from it.
However, today we have far less isolation than we did in 1350. It was possible for a community to simply close itself off from the world for a period of time.
They didn't do a very good job of it. It's estimated that 30-60% of Europe's population was killed.
Purely out of morbid curiosity, what firewall are you using that doesn't have application level support for FTP?
And on the rest... sure, should have raised plenty of red flags. Why would a US company ask a Dutch CA for a certificate? Why would an established site need a new or an extra certificate - a wild card (*.google.com) cert to boot? Now I have no idea how a CA certifies that the requester is actually the owner of a certain domain, it certainly failed badly in this case.
Go buy a certificate some time. There are LOTS of CAs out there who will complete the transaction and give you a certificate in seconds. We'd like to believe that such CAs have some sort of process in place that flags up potentially fraudulent requests for human verification, but as this sort of thing demonstrates that's obviously not the case.
IMV, it's not as bad as it's made out.
The way LDAP authentication is supposed to work is:
1. Client connects to server to find exactly where in the tree the user's information resides (the user's DN). This is not particularly sensitive - it's usually done either anonymously or with an account with very little privileges.
2. Client drops the connection then tries to re-connect using the DN it found out in (1) and the password supplied by the user.
3. If the server responds that the login has succeeded, let the user use the service. If not, refuse.
A number of people have followed the logs on their LDAP servers and established that OS X Lion isn't carrying out step 2 at all. So provided the user ID supplied is valid, the user can log into the computer.
It's important to note that this process is repeated for every process you want to use. Kerberos makes life a little easier (the server supplies a token to say "This user has logged in OK" and that token can be used to authenticate against services that support Kerberos). In any case, the person is logged into the computer but cannot access network resources. Nevertheless, it's an absurd fault that should have been picked up in testing, I have no idea how it could possibly slip the net.
Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it. I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file. Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick.
I have. There is a PAM module that does an LDAP password update. The biggest problem is that there's about a hundred different ways you can configure it, every Linux distribution makes different assumptions about your environment - assumptions which can change between versions - and this almost invariably leads to interoperability problems. Fortunately they all use the same libraries so you can generally dump a known-good set of config files in the appropriate place in /etc and away you go.
PS: There's this crazy idea called "sustainability" I heard about...
I know - which is why I was careful to say "liquid". There's no law that says the fuel has to be made of dead dinosaur.
Easy solution to that - instead of storing the fuel source in the form of a solid lump, make it some sort of energy-dense liquid. That way the manufacturer differentiates themselves on the basis of how much liquid the vehicle requires to travel a given distance and how much liquid their vehicle can store, and the charging station simply pours liquid into some sort of tank until the tank is full.
I have it on good authority that Acorn sold virtually no model As. Apparently it was possible to upgrade the RAM, so it's likely that any that were built wound up being upgraded before they left the warehouse.
(This authority isn't written, it's someone who worked for Acorn at the time. I believe him, mostly because most software required a model B - the RAM was shared between every component in the system so by the time things like video had been included, there was nothing like 16/32K available to programs).
Did you actually read the list or did you just take a quick glance at it?
The following sentences could cause a filter to trip:
"The external male sexual organs - or gonads - are the penis and the testicles. The testicles are enclosed in a sac of skin called the scrotum". (Virtually any biology work concerning sex would suffer equally - "vagina", "clitoris", "orgasm" and "ejaculate" are all in the list).
"The role of chimney sweep Bert in Mary Poppins was played by actor Dick van Dyke".
"As part of this woordwork project, each item is held in place with a single screw."
While I doubt the filter would block on just a single instance, if you're talking about (for example) actor Dick van Dyke, chances are his name's going to appear in the essay several times.
I've never yet seen a filter which was worth a damn. But I have worked in a school (albeit some years ago) and the consensus of opinion there was very much along the lines of "the filtering may never work properly and we may be stuck with something that on the face of it causes as many problems as it solves - but the sort of problems it causes are likely to cost us a lot less than the sort of problems it solves."
I dunno. If there's one thing the last five years have shown, Apple are quite prepared to take calculated risks. Moving to x86 architecture, the iPhone and the iPad were all calculated risks which could easily have gone horribly wrong.
I've thought for some time that the "you can run it on ancient hardware that Windows doesn't support" is a terrible argument in favour of Linux (and F/OSS in general) for a couple of reasons:
1. Software that needs to care about the hardware (such as the Linux kernel or the Mesa library) is not exempt from this being a fast-moving industry, and updating drivers is not without cost in terms of effort. Effort that could be better spent elsewhere.
2. I think it hurts credibility to say "Support for more hardware than Windows!" (But most of the supported hardware is at least five years old, some of it's twenty years old! If you want to use a chipset that's been out less than a few months, expect pain!).
Say we want to further add some animation support to the video renderer for use on the OSD, that code needs to be written for each of Xshm, Xv, OpenGL, VDPAU, VAAPI, XvMC, and PVR-350 framebuffer output. In addition, that's primarily the work of one single guy.
And people wonder why some F/OSS projects have a slow rate of development.
Loads of Western tourists pay ridiculous tour-company prices to spend five days on the Trans-Siberian railway. Some pay even more exaggerated prices to go between countries by ship instead of flying. There's certainly a market for spending such time in a fairly enclosed space.
Good point. It may be possible to make it work, but I'm still not convinced that it would work being sold as a family holiday.
Ya know, I know how they could guarantee this thing pays for itself in a year. Hogwarts express trains, starting in the US, making their way through this tunnel, picking up passengers along the way and stopping in england.
Nah, wouldn't work. Back of an envelope calculations:
As the crow flies, it's 3244 miles from London to Novosibirsk and 5867 miles from Novosibirsk to San Francisco. (I couldn't find a website that would calculate the most efficient rail route, so I'm doing it this way instead), giving us a total of 9,111 miles.
Of course, trains don't follow the shortest route. They follow the route that makes the most sense based on who wants to get what items to what destination and what geography and politics allows. I wouldn't be at all surprised to see the total distance more like 11-12,000 miles.
Now, a high speed train link might theoretically be capable of, what, 120-150mph? (Assuming good conditions along the whole journey, and a rail infrastructure that can support it. Worn out, old railway lines typically have to be travelled over more slowly). But with the sort of distances involved it'll be necessary to stop to pick up supplies, passengers and swap drivers. I'd be surprised if you averaged much more than 50mph across the entire journey. Your Hogwarts Express journey is going to take upwards of 10 days and will cross a minimum of 8 national borders. (US-Canada, Canada-US, US-Russia, Russia-Belarus, Belarus-Poland, Poland-Germany, Germany-France, France-UK). Doubtless the tour operator would take care of visas, but it's something that would have to be booked some way ahead of time - you couldn't just decide to do it tomorrow.
Take a look at the level of comfort in the average sleeper cabin. Consider the idea of that being your home from home for 10 days with the wife and children. Now, about that Hogwart's Express idea...
They don't really support them - not in the same sense that Apple do with the iPhone. Most of the handset manufacturers are still very much stuck in a 10 or 15 year old mindset where they build the phone, put the software together and as soon as it's in mass production they hardly touch the phone's firmware (except in occasional cases of really heinous bugs, and not always then).
If they were all using MS Office, I'm sure they wouldn't mind paying for it. No, the problem is that they'd have to pay as if everyone was using MS Office, because virtualisation and commercial licensing don't play ball.
Funny, that sounds like exactly the sort of clause that is strictly non-negotiable until you're a big enough organisation and you inform the press that you're moving the lot over to a F/OSS alternative.
Non Apple Tables are priced roughly $200-300 too expensive. Get them around $199-$299 and they'll sell like gangbusters just like it did for Android phones in the mobile market.
The thing is, nobody's done that yet. Considering the speed at which this industry normally moves, I have a sneaking suspicion that nobody's succeeded in making a tablet that they can sell for $2-300 and make a profit on.
I can tell that for Greece, part of the EU with the 2-year mandatory warranties, Apple DOES NOT give you a second year. Yes, it is illegal, yes people have managed to fix their products by taking them to court, yes Apple products are more expensive here anyway. And yes, I am sure Apple is betting on fan loyalty to get away with this.
Few technology companies willingly give a two year warranty; you usually have to take them to court to enforce it. Apple is hardly alone here, it's pretty obvious that the majority of companies have decided that most consumers are totally unaware of their rights and have decided it's cheaper to pay for the few that are aware and hope everyone else buys a new item after 18 months than it is to openly announce an extension to their warranty programme.
It'd be nice if the various Trading Standards bodies in Europe were to do something about it, but you don't get something for nothing. I suspect if that were to happen, we'd see some fairly significant price restructuring within a couple of months.
It's unlikely you'll get external storage - Freeview in the UK started encrypting the EPG a few months ago; the only way to get decryption keys to put in your STB is if you agree to make it difficult for people to get recorded programs off the box. I can't see Virgin Media's agreements with the TV companies being dramatically different.
He was then at SuSE. He still is, but he was at SuSE then too.
The only 'difficult' ones are Intel (Can use AMD or ARM though),
ARM don't have any fabs. They are purely an IP licensing company; licensees make the chips.
I think a lot of people don't realise how big Foxconn is. They have factories the size of a reasonable town; you will see all sorts of things in an organisation that size - births, marriages, deaths, the lot - and suicide will be part of it. If you were to talk about Foxconn as a town and say "this town has a quarter the suicide rate of any other town in China", it'd be fantastic. But because we talk about it as a company, it sounds terrible.
Not really. In general terms, printing consists of:
1. Application generates printout in some sort of language that is suitable for describing printed images.
2. OS converts the printout into something the printer can understand.
3. OS sends the result to the printer.
Under more-or-less any Unix, the language used in (1) is Postscript (though IIRC it's PDF in OS X - which is easy enough to translate to Postscript).
So if you use a Postscript printer, the amount of work required in (2) is very little - and for all practical purposes can be said to be driverless. Doesn't work so well for inkjet printers, however, which seldom have the intelligence to handle Postscript.
How many printers have access to the 'net?
More and more of them these days - wireless networking is rapidly becoming the norm in even cheapie consumer inkjets. Apple aren't thinking about the printer you buy today, they're thinking about the printer you might buy in 2-3 years time.