Apparently pink mobile phones are far less likely to be stolen than other colours. I don't know how true this is: I'd also heard that pink is a good colour for luggage because it's easy to spot on the conveyor belt after getting off a plane, but then I was standing in an airport where my black suitcase was easy to spot because it was almost the only one that wasn't pink...
I started wondering when I got my Nokia 770 in 2006 with its 225dpi screen. A few months later, I used a 23" IBM monitor with the same resolution... which cost $10K. And then the reason became quite obvious. Modern displays are solid state parts. Just like ICs, they have a defect rate per area, which translates to dead or stuck pixels. As the feature size increases, the chance of defects increases. The bigger the display, the more chance that a defect will result in some dead or stuck pixels. If you make a single 27" panel, one defect will make it unsellable. If you make the same area of TFT but make it into smaller panels, then a defect will just make one unsellable[1].
There's also the secondary issue that unless you scale the DPI by a factor of 2 users are likely to see aliasing effects in bitmap rendering, and so perceive the display as being worse, which is why we don't see many intermediate sizes.
[1] Or, at least, harder to sell. There are lots of applications, such as control panels for industrial equipment, where a dead pixel or two is unimportant, and companies making these are quite happy to pay a bit less for slightly lower quality small panels. Selling defective 27" displays is much harder.
I didn't pirate it. I enjoyed season 1, and if I remember then I'll add season 2 to my rental queue when it comes out. That means that they'll be getting my money sometime around the time that they're filming season 4, rather than a year earlier. Their choice...
My HTC Desire, which I picked up cheaply because it's two years old, has 576 MB of RAM, so no, it isn't doubtful, it's very plausible. Welcome to 2010.
What makes me laugh are all the fools railing for legalizing pot, but cigarettes and sugary drinks are evil, makes no sense to me. But that's the age of un-reason we live in now.
There's a difference between taxing something and making it illegal. I'm in favour of legalising pot because it irritates me that I pay a load of tax on alcohol and a smaller but still significant amount of tax on coffee, but potheads get to enjoy their favourite drugs tax free. Oh, and for the record I'm in favour of a complete ban on smoking anything in public because I don't think you have the right to make other people inhale your smoke, but you should be free to fill your body with cannabis, heroin, or whatever else you feel like in private.
Not quite. Intel used the feature checks, but also checked for the cpuid instruction returning a tested model. This was not done to intentionally cripple other manufacturers' CPUs (although that was a nice benefit), it was done because other manufacturers (IDT in particular, but occasionally AMD) would set the same feature flags but would not implement a 100% compatible version of the feature. The Intel compiler whitelisted CPUs that had been tested to work and only enable the faster code path in these cases.
Intel's compiler team assumed that people would be more likely to complain if their code did the wrong thing than if it did the right thing slowly. Apparently this was not the case.
it's really hard to argue that any company might like to make a contribution, but decided not to because the project was GPLed
I've seen this happen in companies that have used GPL'd libraries for their in-house codebase. They make some improvements (typically bug fixes, but sometimes new features) and want to give them back. Legal says no because they don't want to publicly acknowledge using GPL'd code in their software now in case they replace the GPL'd code later and redistribute it. These same companies are quite happy to share changes to BSDL libraries because there is no risk of legal liability from doing so and it reduces their maintenance burden.
You seem to assume that companies won't give back to BSDL code. The two big BSDL projects that I contribute to, LLVM and FreeBSD, both get a large amount of code from corporate users. And many of these corporate users chose those projects precisely because they are unwilling to allow any GPL'd code into the building. For them, the choice is either use something BSDL or use something proprietary. Personally, I'd rather they used our code and gave back something (although maybe not all of their improvements) than bought a proprietary codebase and paid developers to improve that. We also benefit indirectly from companies that don't return their changes, because they are training developers to become familiar with our codebase and when they move on they often contribute things back.
I haven't ever seen argue that. It's blatantly obvious that when there is no legal requirement to open code, fewer companies will do so (some still will where it benefits them, but obviously it's going to be an orders of magnitude difference).
Not exactly. It is obvious that where there is a legal requirement to give back then everyone who modifies the software and distributes it will give back changes. It is obvious that where there is no legal requirement, some people who modify and distribute the software will not give back. It is also obvious that, where there is no legal requirement to give back, more people will modify and distribute the code. Finally, it's also obvious that some companies will give back modifications that they don't distribute (and therefore are not legally obliged to share in either case) because it reduces their burden.
The question is whether it's better to have everyone in a smaller set or a subset of a larger set giving back. We've seen a number of high-profile companies, such as Apple, Yahoo, and Netflix, give back code when there was no legal obligation to do so (for example, we've just had a load of improvements to the networking code land in FreeBSD from Netflix because they're using it in their new deployments and really care about performance). We've had code contributions from both large and small companies who won't touch GPL'd code because of the uncertainty over what they'd be required to release: they're 90% sure it's fine, but don't want to risk the 10% when they don't have to. This is especially common for software that is developed in-house with a possibility of spinning out into a separate product later. Most of it stays in house, so the GPL wouldn't require releasing any code either.
Finally, we've seen another category, which is companies using both BSDL and GPL code in house, but only contributing back changes to the BSDL parts because they are afraid of legal liability if they admit to using the GPL'd stuff.
Not in the USA, but in the UK I got a stipend for my entire PhD (I didn't do a masters), which was non-taxable. I didn't have to do any teaching, the only 'catch' was that I had to do some research during that time. I also got a reasonable travel budget - I spent a total of over 20 weeks away (travel, food, and accommodation paid) during the three years it took to do my PhD.
I suppose the catch is that I could have been earning more during that time if I'd got a proper job instead of doing a PhD, but since I wrote my first book and a regular column for much of that time to supplement my stipend, I didn't consider it to much of a catch.
$100 is probably not enough to pay the people who will mark the exams. Most universities allow external students: those who are not taught by the university but simply show up and take the exams, and you'd be hard pressed to find any that do so for $100. A masters course typically involves a dissertation that is at least 100 pages. Just reading it is going to take several hours. If you can do it in five hours (which is pretty good going for a thorough read of a masters dissertation) then you're talking $20/hour, and not leaving any more time for marking the other exams.
I would not trust a $100 masters degree (unless that's just $100 paid by the student, with the rest funded from elsewhere) for the simple reason that it is not feasible to do a proper assessment of the student for that little money. $1000 might be quite feasible though...
They are not distributing Linux services. They have released some driver code that is now in the Linux kernel. They are renting VM space to customers. Customers may choose to install Windows, Linux, or something else in those VMs (Microsoft, NetApp an Citrix just added Hyper-V support to FreeBSD and are in the process of pushing that code upstream, so that's about to become a third choice), but it's the customer's liability if it's something that infringes patents. There is a good chance, however, that Microsoft customers will get some kind of indemnity for infringing Microsoft patents while using a Microsoft service...
Nope. Anyone can install stuff on their own device by just turning off the secure boot mechanism. The $99 buys you a signing key that lets you install your software on anyone's machine. Essentially, paying $99 gets you back to the situation you were in without secure boot being enabled, at least with respect to your software.
If anyone can pay $99 to get a key that lets them install malware in anyone's firmware, then there is obviously no security in the system. I'd have thought this would be excellent grounds for an antitrust investigation...
DMCA take-down notices are only useful for sites that are are using the DMCA safe harbour provisions. For example, by complying with DMCA take-down notices, YouTube is not liable for copyright infringement by their users. This does not apply to people putting their own content on their own web sites: they are always liable, so you're back to it being a straightforward case of copyright infringement. You can take them to court for this (in addition to breach of contract), but that's still expensive.
Oh, I'd agree about that. Scripting in something like Lua, which is a 200KB binary that can be embedded in the tool without much overhead would make sense. Trying to distribute Python programs is usually a disaster in my experience, but that doesn't make the original poster's complaint valid.
Apple provides iWork on iOS and OS X. Apple has a licensing deal with Microsoft that gives them access to the file formats for office, and can work moderately well with them. On OS X, for example, you can view PowerPoint presentations and Word documents in QuickView from the Finder.
Programming is about picking the right tool for the job (which is never Python, but I digress). There are not going to be 100 users running an admin tool at once. Even that tool is not going to be loading the CPU, because it is going to be spending almost all of its time calling into C libraries. If the choice is writing it in a language that makes it easy to get bug-free and which does not impose any user-visible cost, or writing it in a language that makes what you want to do (e.g. string processing) error prone, likely to be buggy, and does not run detectably faster, then you are an idiot if you pick option 2.
Given that they are using FreeBSD on their new CDN (and most of their new back-end infrastructure), why do you think it would make Linux support more likely?
While I'm certainly not a fan of Python, it's clear that they are leaving the high performance parts in C, and just using Python for scripting. Samba comes with a lot of tools that are not performance critical. For example, the smbtree utility needs to print a pretty tree of the current network from the results of a scan. If the scan is done by the core C code, there's no reason why you can't write the part that parses command-line options, prompts for passwords, and displays the output in an interpreted scripting language: even if it runs at 1% of the speed of C code, users won't notice the difference because almost all of the time will be spent in the code doing the I/O.
Slashdot Mirror
Thank Ford for that!
Apparently pink mobile phones are far less likely to be stolen than other colours. I don't know how true this is: I'd also heard that pink is a good colour for luggage because it's easy to spot on the conveyor belt after getting off a plane, but then I was standing in an airport where my black suitcase was easy to spot because it was almost the only one that wasn't pink...
I started wondering when I got my Nokia 770 in 2006 with its 225dpi screen. A few months later, I used a 23" IBM monitor with the same resolution... which cost $10K. And then the reason became quite obvious. Modern displays are solid state parts. Just like ICs, they have a defect rate per area, which translates to dead or stuck pixels. As the feature size increases, the chance of defects increases. The bigger the display, the more chance that a defect will result in some dead or stuck pixels. If you make a single 27" panel, one defect will make it unsellable. If you make the same area of TFT but make it into smaller panels, then a defect will just make one unsellable[1].
There's also the secondary issue that unless you scale the DPI by a factor of 2 users are likely to see aliasing effects in bitmap rendering, and so perceive the display as being worse, which is why we don't see many intermediate sizes.
[1] Or, at least, harder to sell. There are lots of applications, such as control panels for industrial equipment, where a dead pixel or two is unimportant, and companies making these are quite happy to pay a bit less for slightly lower quality small panels. Selling defective 27" displays is much harder.
I didn't pirate it. I enjoyed season 1, and if I remember then I'll add season 2 to my rental queue when it comes out. That means that they'll be getting my money sometime around the time that they're filming season 4, rather than a year earlier. Their choice...
My HTC Desire, which I picked up cheaply because it's two years old, has 576 MB of RAM, so no, it isn't doubtful, it's very plausible. Welcome to 2010.
What makes me laugh are all the fools railing for legalizing pot, but cigarettes and sugary drinks are evil, makes no sense to me. But that's the age of un-reason we live in now.
There's a difference between taxing something and making it illegal. I'm in favour of legalising pot because it irritates me that I pay a load of tax on alcohol and a smaller but still significant amount of tax on coffee, but potheads get to enjoy their favourite drugs tax free. Oh, and for the record I'm in favour of a complete ban on smoking anything in public because I don't think you have the right to make other people inhale your smoke, but you should be free to fill your body with cannabis, heroin, or whatever else you feel like in private.
ATi's drivers sucked back when there was competition for video cards too. It's not a new thing.
Not quite. Intel used the feature checks, but also checked for the cpuid instruction returning a tested model. This was not done to intentionally cripple other manufacturers' CPUs (although that was a nice benefit), it was done because other manufacturers (IDT in particular, but occasionally AMD) would set the same feature flags but would not implement a 100% compatible version of the feature. The Intel compiler whitelisted CPUs that had been tested to work and only enable the faster code path in these cases.
Intel's compiler team assumed that people would be more likely to complain if their code did the wrong thing than if it did the right thing slowly. Apparently this was not the case.
it's really hard to argue that any company might like to make a contribution, but decided not to because the project was GPLed
I've seen this happen in companies that have used GPL'd libraries for their in-house codebase. They make some improvements (typically bug fixes, but sometimes new features) and want to give them back. Legal says no because they don't want to publicly acknowledge using GPL'd code in their software now in case they replace the GPL'd code later and redistribute it. These same companies are quite happy to share changes to BSDL libraries because there is no risk of legal liability from doing so and it reduces their maintenance burden.
You seem to assume that companies won't give back to BSDL code. The two big BSDL projects that I contribute to, LLVM and FreeBSD, both get a large amount of code from corporate users. And many of these corporate users chose those projects precisely because they are unwilling to allow any GPL'd code into the building. For them, the choice is either use something BSDL or use something proprietary. Personally, I'd rather they used our code and gave back something (although maybe not all of their improvements) than bought a proprietary codebase and paid developers to improve that. We also benefit indirectly from companies that don't return their changes, because they are training developers to become familiar with our codebase and when they move on they often contribute things back.
I haven't ever seen argue that. It's blatantly obvious that when there is no legal requirement to open code, fewer companies will do so (some still will where it benefits them, but obviously it's going to be an orders of magnitude difference).
Not exactly. It is obvious that where there is a legal requirement to give back then everyone who modifies the software and distributes it will give back changes. It is obvious that where there is no legal requirement, some people who modify and distribute the software will not give back. It is also obvious that, where there is no legal requirement to give back, more people will modify and distribute the code. Finally, it's also obvious that some companies will give back modifications that they don't distribute (and therefore are not legally obliged to share in either case) because it reduces their burden.
The question is whether it's better to have everyone in a smaller set or a subset of a larger set giving back. We've seen a number of high-profile companies, such as Apple, Yahoo, and Netflix, give back code when there was no legal obligation to do so (for example, we've just had a load of improvements to the networking code land in FreeBSD from Netflix because they're using it in their new deployments and really care about performance). We've had code contributions from both large and small companies who won't touch GPL'd code because of the uncertainty over what they'd be required to release: they're 90% sure it's fine, but don't want to risk the 10% when they don't have to. This is especially common for software that is developed in-house with a possibility of spinning out into a separate product later. Most of it stays in house, so the GPL wouldn't require releasing any code either.
Finally, we've seen another category, which is companies using both BSDL and GPL code in house, but only contributing back changes to the BSDL parts because they are afraid of legal liability if they admit to using the GPL'd stuff.
Not in the USA, but in the UK I got a stipend for my entire PhD (I didn't do a masters), which was non-taxable. I didn't have to do any teaching, the only 'catch' was that I had to do some research during that time. I also got a reasonable travel budget - I spent a total of over 20 weeks away (travel, food, and accommodation paid) during the three years it took to do my PhD.
I suppose the catch is that I could have been earning more during that time if I'd got a proper job instead of doing a PhD, but since I wrote my first book and a regular column for much of that time to supplement my stipend, I didn't consider it to much of a catch.
$100 is probably not enough to pay the people who will mark the exams. Most universities allow external students: those who are not taught by the university but simply show up and take the exams, and you'd be hard pressed to find any that do so for $100. A masters course typically involves a dissertation that is at least 100 pages. Just reading it is going to take several hours. If you can do it in five hours (which is pretty good going for a thorough read of a masters dissertation) then you're talking $20/hour, and not leaving any more time for marking the other exams.
I would not trust a $100 masters degree (unless that's just $100 paid by the student, with the rest funded from elsewhere) for the simple reason that it is not feasible to do a proper assessment of the student for that little money. $1000 might be quite feasible though...
They are not distributing Linux services. They have released some driver code that is now in the Linux kernel. They are renting VM space to customers. Customers may choose to install Windows, Linux, or something else in those VMs (Microsoft, NetApp an Citrix just added Hyper-V support to FreeBSD and are in the process of pushing that code upstream, so that's about to become a third choice), but it's the customer's liability if it's something that infringes patents. There is a good chance, however, that Microsoft customers will get some kind of indemnity for infringing Microsoft patents while using a Microsoft service...
Nope. Anyone can install stuff on their own device by just turning off the secure boot mechanism. The $99 buys you a signing key that lets you install your software on anyone's machine. Essentially, paying $99 gets you back to the situation you were in without secure boot being enabled, at least with respect to your software.
If anyone can pay $99 to get a key that lets them install malware in anyone's firmware, then there is obviously no security in the system. I'd have thought this would be excellent grounds for an antitrust investigation...
DMCA take-down notices are only useful for sites that are are using the DMCA safe harbour provisions. For example, by complying with DMCA take-down notices, YouTube is not liable for copyright infringement by their users. This does not apply to people putting their own content on their own web sites: they are always liable, so you're back to it being a straightforward case of copyright infringement. You can take them to court for this (in addition to breach of contract), but that's still expensive.
Presumably judge.me will be able to afford to hire local lawyers to take them to a local court for breach of contract if they refuse to pay.
Oh, I'd agree about that. Scripting in something like Lua, which is a 200KB binary that can be embedded in the tool without much overhead would make sense. Trying to distribute Python programs is usually a disaster in my experience, but that doesn't make the original poster's complaint valid.
Ah, they are truly living the American Dream(tm).
Apple provides iWork on iOS and OS X. Apple has a licensing deal with Microsoft that gives them access to the file formats for office, and can work moderately well with them. On OS X, for example, you can view PowerPoint presentations and Word documents in QuickView from the Finder.
Programming is about picking the right tool for the job (which is never Python, but I digress). There are not going to be 100 users running an admin tool at once. Even that tool is not going to be loading the CPU, because it is going to be spending almost all of its time calling into C libraries. If the choice is writing it in a language that makes it easy to get bug-free and which does not impose any user-visible cost, or writing it in a language that makes what you want to do (e.g. string processing) error prone, likely to be buggy, and does not run detectably faster, then you are an idiot if you pick option 2.
Given that they are using FreeBSD on their new CDN (and most of their new back-end infrastructure), why do you think it would make Linux support more likely?
While I'm certainly not a fan of Python, it's clear that they are leaving the high performance parts in C, and just using Python for scripting. Samba comes with a lot of tools that are not performance critical. For example, the smbtree utility needs to print a pretty tree of the current network from the results of a scan. If the scan is done by the core C code, there's no reason why you can't write the part that parses command-line options, prompts for passwords, and displays the output in an interpreted scripting language: even if it runs at 1% of the speed of C code, users won't notice the difference because almost all of the time will be spent in the code doing the I/O.
If you build enough rockets, eventually the lawyers learn to keep away...