Just release it for the most popular distro(-family), which is undeniably Ubuntu (covering Debian and Mint as well).
Actually, Ubuntu is not binary compatible with Debian, so to get Ubuntu packages running on Debian you need to recompile them, which won't be possible for closed source stuff.
Who cares whether or not it'll sell if you just build one for yourself? It's out of reach of the average person, but probably not a more talented geek. You can buy current gen ARM CPUs for fairly reasonably prices, as well as tablet screens thanks to economies of scale. Add a battery, bluetooth/wifi/gps chip and anything else you feel like and you're done. Not necessarily the easiest way to go about things, but it's the only way to get every feature you desire when you don't fall into the main demographic.
MS made (and still makes) some of the first and best mass-market ergonomic keyboards.
Microsoft used to make some of the best mass-market keyboards. Their new ones are absolute crap though - no tactile response whatsoever. This appears to be by design - they advertise it as 'soft touch', and while it's pretty quiet, it's also horribly gummy and really slows you down.
Unless you're playing tricks with shims and wrappers, such as by running ZFS in userspace somehow, or forcing end users to do all the work of setting up ZFS rather than making it quick and easy to set up, you're probably violating the CDDL and GPL by distributing ZFS with a Linux distribution.
The official position is that the license conflict just means you can't compile it into the kernel, not that you can't publish it as a kernel module.
I acknowledge that there is some controversy over whether kernel modules are considered derivative works, but the fact that proprietary drivers do exist and are often available in the non-free sections of repositories contradicts the idea that the licensing issue alone is enough to stop it. Furthermore, Linus' opinion on the matter seems to be that modules developed for other OSes which are then ported to Linux should not be considered derivative works.
But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour. Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it. Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area. Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking). So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived. Linus ---http://kerneltrap.org/node/1735
So legally, there aren't any issues with running ZFS under Linux, or even distributing binary kernel modules for it. Legally there's no distinction based on the relative difficulty of installation, it's merely a question of whether it's compiled into the kernel or not.
ZFS does work under Linux - my understanding is that the only reason you don't find it in the main repositories (Ubuntu has it in a PPA) is a licensing issue. Or is there some technical issue I'm missing?
I've read Carnegie's work, and disagreed fundamentally with it for a simple reason: priorities. Carnegie prioritises getting along with people above establishing the truth or the end result, and that's fair enough given his book was focused on befriending people. But Linus' top priority is the stability of the kernel; social niceties come after that.
While I personally wouldn't respond the way he did, I can certainly understand his perspective and I think that you absolutely need zero tolerance for those kinds of patches if you want to keep the kernel in good shape. Excessive bluntness is preferable to excessive subtlety in this case.
Kontact. Admittedly, Kmail's interface is a bit lacking compared to Thunderbird, but Kontact's killer feature is that it has email, an address book, personal organizer, and RSS reader, all of which you can sync across multiple devices if you run Kolab on a server. If you want access to all that information across multiple devices, you either have to put your data in the cloud, use a commercial solution, or use a varied collection of different programs.
Today, you are expected to work 60+ hours a week, get divorced, have health issues, even die on the job (had multiple deaths in the current project so far : cancer, heart attacks, some among young people who shouldn't be having these problems) - as bad as building a big steel bridge or skyscraper).
Same goes for us down in Australia. I've had great experiences with Amazon and bought a bunch of books from them recently, but it's virtually impossible to find electronics that ship outside the US on there.
Why, that sounds almost as if they would be held accountable for their actions, to the extent that it might actually be disadvantageous to break the law...
The very reason it's a clusterfuck is because of the fragmentation these guys are trying to address. Each device has a different kernel, even those that use the same SoC (because the GPIOs, etc. are hardcoded). That means that the developers efforts are fragmented - only a small number of people see the bugs and put in the effort to fix them, which undermines Linus' law. 3.7 will help, but there's still a lot to be done before ARM has the kind of compatibility that x86 does.
tldr: These guys are doing useful, important work that will vastly improve the state of Linux ARM.
There's a difference between premature optimization and software bloat. I can see absolutely no reason one program should take up 2+ orders of magnitude more resources than a competing product with 90% of the features.
Once upon a time there was an idea to target both phones and tablets - what happened to that? It seems like they're only concentrating on tablets now. -someone who was really looking forward to running KDE on his phone
Here's a useful reference point: I ordered one from both element14 and RS at the same time. The RS one arrived several weeks after the one from element14. I ordered another one from element14 more recently, and it arrived in under 3 weeks.
AFAICT, most of the people complaining ordered theirs from RS. I suspect part of the reason may be that RS is using a completely separate website and therefore likely has a completely separate administrative process for fulfilling orders, which isn't as capable. Element14 just added them as items to their regular site, so they aren't subject to the same limitations. (I'd say that was a pretty good move on their part, given that I've since ordered lots of more obscure components from them.)
Here's some perspective: I have an Android tablet which I installed Debian on. The 2.6 kernel I use on it is a modified Android kernel, and the 3.1 is a beta kernel provided by Nvidia. I am yet to find a device that works under x86 Linux that is not supported by either of these kernels. Now, I'm more than willing to say that the device is a hack, plain and simple. There are plenty of bugs, some of which are show stoppers (there's a reason I use 2 different kernels on a regular basis). Yet this franken-tablet with a small handful of people intermittently working on it has better driver support than a mature product like the Raspberry Pi with hundreds of developers. That should say something about the nature of the bugs.
It's pretty much standard at my university (in Australia) to post video lectures and slides online, and I'd say it's invaluable. The slides are great if you need to look something up or fill in something you missed during the lecture, but the videos are better if you missed the lecture entirely (you could have a clash, been ill, etc.) since the lecturer often goes into additional details and explanations beyond what's in the slides, or does a derivation in the margins.
Slashdot Mirror
Just release it for the most popular distro(-family), which is undeniably Ubuntu (covering Debian and Mint as well).
Actually, Ubuntu is not binary compatible with Debian, so to get Ubuntu packages running on Debian you need to recompile them, which won't be possible for closed source stuff.
...for building a tablet that nobody will buy.
Who cares whether or not it'll sell if you just build one for yourself? It's out of reach of the average person, but probably not a more talented geek. You can buy current gen ARM CPUs for fairly reasonably prices, as well as tablet screens thanks to economies of scale. Add a battery, bluetooth/wifi/gps chip and anything else you feel like and you're done. Not necessarily the easiest way to go about things, but it's the only way to get every feature you desire when you don't fall into the main demographic.
MS made (and still makes) some of the first and best mass-market ergonomic keyboards.
Microsoft used to make some of the best mass-market keyboards. Their new ones are absolute crap though - no tactile response whatsoever. This appears to be by design - they advertise it as 'soft touch', and while it's pretty quiet, it's also horribly gummy and really slows you down.
Unless you're playing tricks with shims and wrappers, such as by running ZFS in userspace somehow, or forcing end users to do all the work of setting up ZFS rather than making it quick and easy to set up, you're probably violating the CDDL and GPL by distributing ZFS with a Linux distribution.
The official position is that the license conflict just means you can't compile it into the kernel, not that you can't publish it as a kernel module.
I acknowledge that there is some controversy over whether kernel modules are considered derivative works, but the fact that proprietary drivers do exist and are often available in the non-free sections of repositories contradicts the idea that the licensing issue alone is enough to stop it. Furthermore, Linus' opinion on the matter seems to be that modules developed for other OSes which are then ported to Linux should not be considered derivative works.
But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?
THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.
Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.
Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.
Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).
So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived.
Linus
---http://kerneltrap.org/node/1735
So legally, there aren't any issues with running ZFS under Linux, or even distributing binary kernel modules for it. Legally there's no distinction based on the relative difficulty of installation, it's merely a question of whether it's compiled into the kernel or not.
ZFS does work under Linux - my understanding is that the only reason you don't find it in the main repositories (Ubuntu has it in a PPA) is a licensing issue. Or is there some technical issue I'm missing?
I've read Carnegie's work, and disagreed fundamentally with it for a simple reason: priorities. Carnegie prioritises getting along with people above establishing the truth or the end result, and that's fair enough given his book was focused on befriending people. But Linus' top priority is the stability of the kernel; social niceties come after that.
While I personally wouldn't respond the way he did, I can certainly understand his perspective and I think that you absolutely need zero tolerance for those kinds of patches if you want to keep the kernel in good shape. Excessive bluntness is preferable to excessive subtlety in this case.
"News for nerds, stuff that matters."
I'd much rather hear about this than yet another episode in the life of John McAfee.
$89 Exynos4412 1.7Ghz ARM Cortex-A9 Quad Core, 10/100Mbps Ethernet, 2 x High speed USB2.0 Host,HDMI, SD Slot, Headphone jack
http://www.hardkernel.com/renewal_2011/products/prdt_info.php
The Exynos 4 is actually pretty recent tech. Once again I am tempted to design my own phone from scratch....
Kontact. Admittedly, Kmail's interface is a bit lacking compared to Thunderbird, but Kontact's killer feature is that it has email, an address book, personal organizer, and RSS reader, all of which you can sync across multiple devices if you run Kolab on a server. If you want access to all that information across multiple devices, you either have to put your data in the cloud, use a commercial solution, or use a varied collection of different programs.
Thanks for that post. It's rare to see people bringing balance to the conversation by offering perspectives like that here. We need more of it.
Microsoft should simply start to open source their products. Must not be GPL, could be "here is our code but you can't use it" license.
That's not what open source means.
Today, you are expected to work 60+ hours a week, get divorced, have health issues, even die on the job (had multiple deaths in the current project so far : cancer, heart attacks, some among young people who shouldn't be having these problems) - as bad as building a big steel bridge or skyscraper).
The Japanese have a word for this - karoshi.
Same goes for us down in Australia. I've had great experiences with Amazon and bought a bunch of books from them recently, but it's virtually impossible to find electronics that ship outside the US on there.
No, these were the projections accounting for the UI Formerly Known as Metro. They just underestimated how bad it would be.
Why, that sounds almost as if they would be held accountable for their actions, to the extent that it might actually be disadvantageous to break the law...
The very reason it's a clusterfuck is because of the fragmentation these guys are trying to address. Each device has a different kernel, even those that use the same SoC (because the GPIOs, etc. are hardcoded). That means that the developers efforts are fragmented - only a small number of people see the bugs and put in the effort to fix them, which undermines Linus' law. 3.7 will help, but there's still a lot to be done before ARM has the kind of compatibility that x86 does.
tldr: These guys are doing useful, important work that will vastly improve the state of Linux ARM.
For that matter Linaro has been making ARM patchsets for various hardware for over 10 years (maybe even longer!).
Citation needed. According to wikipedia, Linaro was only founded 2 years ago.
This is also true in other Commonwealth countries, such as Australia, Canada, etc.
KDE is hardly an alternative desktop - it has more in common with Gnome (in terms of popularity) than XFCE.
There's a difference between premature optimization and software bloat. I can see absolutely no reason one program should take up 2+ orders of magnitude more resources than a competing product with 90% of the features.
Once upon a time there was an idea to target both phones and tablets - what happened to that? It seems like they're only concentrating on tablets now.
-someone who was really looking forward to running KDE on his phone
Here's a useful reference point: I ordered one from both element14 and RS at the same time. The RS one arrived several weeks after the one from element14. I ordered another one from element14 more recently, and it arrived in under 3 weeks.
AFAICT, most of the people complaining ordered theirs from RS. I suspect part of the reason may be that RS is using a completely separate website and therefore likely has a completely separate administrative process for fulfilling orders, which isn't as capable. Element14 just added them as items to their regular site, so they aren't subject to the same limitations. (I'd say that was a pretty good move on their part, given that I've since ordered lots of more obscure components from them.)
I have Word docs in a git repository. Diffs seem to work fine, though I haven't tried doing any merges yet.
The fact that this wasn't fixed during development is pretty telling. There are plenty of commonplace devices that simply don't work, the most notable being powered USB hubs.
Here's some perspective: I have an Android tablet which I installed Debian on. The 2.6 kernel I use on it is a modified Android kernel, and the 3.1 is a beta kernel provided by Nvidia. I am yet to find a device that works under x86 Linux that is not supported by either of these kernels. Now, I'm more than willing to say that the device is a hack, plain and simple. There are plenty of bugs, some of which are show stoppers (there's a reason I use 2 different kernels on a regular basis). Yet this franken-tablet with a small handful of people intermittently working on it has better driver support than a mature product like the Raspberry Pi with hundreds of developers. That should say something about the nature of the bugs.
It's pretty much standard at my university (in Australia) to post video lectures and slides online, and I'd say it's invaluable. The slides are great if you need to look something up or fill in something you missed during the lecture, but the videos are better if you missed the lecture entirely (you could have a clash, been ill, etc.) since the lecturer often goes into additional details and explanations beyond what's in the slides, or does a derivation in the margins.