Just because you don't like company A, and you don't like company B, doesn't mean that someone else working for B is like him working for A from his perspective.
My understanding is that the distaste for Sony came from it trying to lock out developers and hackers who wanted to put their own stuff into the PS3 ecosystem. Facebook lets developers in*, the developers are just not allowed to take users out.
* Seriously; it seems every third week,at some point navigating to facebook.com lands me on some kind of phishing page or scam poll. It'd be a lot easier for FB to avoid that kind of vulnerability if they were far more draconian about developer access.
My guess is that they wanted to do comparisons between the most common and developer-popular languages with strong typing and strong object models. That reflects an investment in those particular design idioms. Selecting for language features will narrow the field somewhat.
Among established languages, I assume it's common knowledge that C++ has been the highest-performance language, for definitions of performance non-inclusive of developer time spent optimizing*. Nevertheless, there are always new languages being developed by enthusiasts, academics--even some businesses, which approach the problem of high-performance code from different angles.
* God, to say anything accurate and comparative on the subject, one has to add so many scope qualifiers that it becomes, well, almost meaningless...
"Translation Party" was awesome, and it led me to figure out how to use translation tools reasonably effectively to communicate to people with whom I don't share a common language.
(Keep re-wording one's English form until it survives a round-trip intact. Won't necessarily work for some languages, but it seemed to produce good results)
The ultimate solution to most of those appears to be, "have to do it fifty times, and assign one job to a person".
That said, not all problems are so easily dealt with as bulk operations. Perhaps you have some real need to take one item and spit the work up among multiple people. The real driving force for all the scenarios I can think of is a desire or need for an upper bound on job latency.
I do this kind of work as my day job. I've also got some experience in managing groups of coders (at work, not particularly via the site linked to in my sig). The problems are remarkably related. You know that job you had where there were meetings held once a day to synchronize between multiple groups? You know how you hated that those meetings waste your time? That's the kind of overhead that parallel programmers weigh and try to avoid when writing their code.
Who knows? Perhaps "lockless" algorithms will find some particular use in real-world management problems.
It was in no way clear to the court in the beginning that SCO's case was weak. It was clear to us, but we were technical experts with no small degree of bias. It may have been clear to people in IT departments, but it wasn't have been clear to the people who control company's purse strings.
Cross-licensing agreements have been in place between big names for decades. AMD and Intel have them. Intel was in the habit of making them before AMD existed.
You don't need to worry about the likes of them. If they're large enough to have the need and clout to sign cross-licensing agreements, they're large enough that they can handle patent submariners. Even if they lose their court case and are ordered to pay, they'll go on doing what they were doing anyway; if they didn't expect to make money on it in the first place, they wouldn't have done it. Even if they're ordered to pay settlement fees, they'll still continue to make money.
There was just as much (even more) ambient fear 2-5 years ago as there is today, but it's really not something worth getting in a twist over. You really can't halt something like this, because for every big-name company that backs off, three more are waiting in the shadows to get in on the market.
That's not the precise question. The precise question is, "why does the involvement of corporate lawyers from every major tech company in the world lead things to a standstill with everyone afraid of potential lawsuits for any new development or implementation utilizing FOSS as the starting point?"
Nothing you describe makes developing off of Linux, Android or other open-source or free-software products any more of a risk than it was a year ago, perhaps even two years ago. We've seen this pattern of events before, with SCO, but Linux kept growing. We've seen IP risks come into play with BSD, with AT&T being the plaintiff, but UNIX kept growing.
I have absolutely no doubt that, somewhere, the Linux kernel and/or minimal userland runtime infringes upon patents held by Microsoft, IBM, Intel, AMD, Google and others, but the most you see is Microsoft threatening to pull a trigger they've never dared to in the past. Why? Because the other big names would bring their own patent portfolios to bear on them, because all the big players except Microsoft and Apple heavily depend on Linux, and the world of patents is one giant pile of Mutually Assured Destruction.
The patent sea submariners won't be able to do any more damage than they've ever been able to do, and they're not interested in innovators; innovators are almost invariably too small of fish for them to care about.
but now that the corporate lawyers from every major tech company in the world has gotten involved things will come to a standstill with everyone afraid of potential lawsuits for any new development or implementation utilizing FOSS as the starting point.
Embrace and extend isn't usually a bad thing, as long as it isn't embrace, extend and don't disallow anyone else from implementing a compatible extension.
The best documentation may be source code, and documenting the extension is a Really Good Thing if you depend on ISVs at all, but even the lack of documentation doesn't make embrace-and-extend a bad thing.
What makes embrace-and-extend a bad thing is disallowance of alternate implementation through general legal mechanisms like anti-reverse-engineering provisions in law, as well as specific legal mechanisms like patents.
This the third time I'll have attempted to post a reply to this. (I don't know where the other two went)
It's not GNOME that will suffer bitrot. GNOME has many users across many distributions. What will suffer bitrot is the glue code that integrates GNOME with Ubuntu core components and behaviors.
Desktop metaphor has been around since the 80s. I don't know when a 'Launcher' button first came around, but it didn't hit Windows until Windows 95/Windows NT4, and I remember it being weird and confusing for those of us who had been accustomed to Win3.1's Program Manager. Even worse was the addition of that 'X' button in the upper-right corner of windows. I closed many applications I hadn't meant to while trying to maximize them.
The "desktop" metaphore has been undergoing changes every few years for as long as it's been around. Personally, I think overlapped windows are a poor deal to begin with, but it's taking mobile devices and limited screen space for more people to notice that.
Microsoft comes out with a new, infuriating rewrite of the desktop every 4-6 years. I really don't think Linux poking around every 2-3 years is going to have a a major offputting effect to people who are new to Linux. It's much more offputting to those of us who have been using Linux on the desktop for over a decade.
Not GNOME, but the bindings and glue that integrate GNOME with Ubuntu. GNOME will see plenty of users and involvement by the nature of it being a widespread project included with many distros. That's not at issue. What's at issue is the glue code that Ubuntu devs write and maintain that integrate GNOME with the Ubuntu in general and specific fashions.
Heh. I suspect a number of DR and armor rules were being misapplied by whoever set up a Spartan-vs-Fallout comparison.
Your argument such degrees of configurability not being for everyone is spot-on, of course. However, I've not found any other distro that handles preserving system configuration alterations as well as Gentoo does.:)
Not GNOME, but GNOME's integration with Ubuntu's system controls. GNOME itself won't see bitrot because, as a unit, GNOME sees a lot of testing. However, the glue code between GNOME and Ubuntu will suffer, as while GNOME will see a lot of users, and Ubuntu will see a lot of users, the combinanation of GNOME+Ubuntu will see fewer users.
You've got me lusting after setting up a 92-machine computer lab as a Gentoo distcc setup.
Gentoo is awful in that it takes a long time to get things just right, but it's awesome that things can be made far more 'just right' than any other distro I've ever used.
Except that anything that's not part of the primary feature set or user interaction path on Ubuntu tends to see bitrot, more so than in distros that don't try to tie everything together.
The reason is obvious; Ubuntu devs try very hard to create a unified and convenient experience (and they do, for a large class of users), and that work leads to the creation of code and features that sees a large amount of testing and use for the general case. They don't see a lot of testing for people who don't use the general case. For example, I was forced to switch away from 'wmii' when I discovered that key Ubuntu features didn't function well (or at all) if one didn't have a FreeDesktop.org tray for interacting with some Ubuntu core control mechanisms, and there were no discoverable command-line-driven accessors to those control mechanisms. This general class of problems has hit me every time Ubuntu saw a new six-month-release cycle.
The first response is usually "try an LTS release." LTS releases are nice for fire-and-don't-quite-forget systems and servers, where one can run apt-get update && apt-get-upgrade, but not need to install new packages often, if ever. On a desktop or workstation, or anything where any kind of development needs to be done, even Ubuntu's 3yr release cycle (which kicked Debian's butt when first adhered to) is slow. Proprietary vendors tend to release packages for the latest 6mo release, and the latest LTS if you're lucky.
The second response is usually "check the forums." The forums are (and always have been) a mess whenever one wanted to try something not-really-bleeding edge; often enough one would come across a thread four years out of date after seeing more recent threads referring queries to the "established" thread. In that time, APIs change, and even entire toolchains get deprecated and replaced.
The third response is usually "file bug reports!" or "contribute some changes!"... I've got friends who are Ubuntu devs or dedicated advocates, and I sometimes hear this from them, too. I don't have the time. Really, I don't. I managed to file three bugs this year. Two against Ekiga, and one against LibreOffice. That's a record for me. I didn't have time to follow up on questions around the Ekiga bugs, and I was fortunate someone else was able to reproduce the LibreOffice bug.
I'm not saying Ubuntu is inherently horrible; at times, it's the best tool for the job. However, I don't think the claim that getting back to tried-and-true is "only a few clicks away" exhibits an awareness of how rapidly non-default configurations on Ubuntu undergo bitrot.
I use Ubuntu only when I need something up and running fast. I use Debian or Gentoo when I need it up and running right. (Often Ubuntu server can stand in for Debian in server circumstances. It depends on whose LTS release has the package/version pairs I need)
Would this be the case in question re Amstrad v Western Digital? Also, the WP article on Amstrad talks about them suing Seagate, which sounds like it might stand correction.
Used to be you couldn't use a BSD license on Google Code, but that's apparently changed. My only remaining complaint is that there isn't a good way for me to take a project on Google Code (e.g. "dastoob") and assign a domain to it. I've got dastoob.net set up right now to 301 redirect to the relevant Google Code page.
Slashdot Mirror
Just because you don't like company A, and you don't like company B, doesn't mean that someone else working for B is like him working for A from his perspective.
My understanding is that the distaste for Sony came from it trying to lock out developers and hackers who wanted to put their own stuff into the PS3 ecosystem. Facebook lets developers in*, the developers are just not allowed to take users out.
* Seriously; it seems every third week,at some point navigating to facebook.com lands me on some kind of phishing page or scam poll. It'd be a lot easier for FB to avoid that kind of vulnerability if they were far more draconian about developer access.
My guess is that they wanted to do comparisons between the most common and developer-popular languages with strong typing and strong object models. That reflects an investment in those particular design idioms. Selecting for language features will narrow the field somewhat.
Perhaps this data would be more interesting.
Among established languages, I assume it's common knowledge that C++ has been the highest-performance language, for definitions of performance non-inclusive of developer time spent optimizing*. Nevertheless, there are always new languages being developed by enthusiasts, academics--even some businesses, which approach the problem of high-performance code from different angles.
* God, to say anything accurate and comparative on the subject, one has to add so many scope qualifiers that it becomes, well, almost meaningless...
Ah, got it. Thanks.
(Also, for the record, I recognize I should have said "domUs" for less-privileged guest VMs)
(Also, Slashdot's commenting system is driving me batty. *flies away*)
My understanding of Xen was that it was a hypervisor, had a dom0 guest VM for administering the hypervisor, and dom0s for less privileged guest VMs.
Is this about running Xen inside Xen, or am I way off target?
"Translation Party" was awesome, and it led me to figure out how to use translation tools reasonably effectively to communicate to people with whom I don't share a common language.
(Keep re-wording one's English form until it survives a round-trip intact. Won't necessarily work for some languages, but it seemed to produce good results)
The ultimate solution to most of those appears to be, "have to do it fifty times, and assign one job to a person".
That said, not all problems are so easily dealt with as bulk operations. Perhaps you have some real need to take one item and spit the work up among multiple people. The real driving force for all the scenarios I can think of is a desire or need for an upper bound on job latency.
I do this kind of work as my day job. I've also got some experience in managing groups of coders (at work, not particularly via the site linked to in my sig). The problems are remarkably related. You know that job you had where there were meetings held once a day to synchronize between multiple groups? You know how you hated that those meetings waste your time? That's the kind of overhead that parallel programmers weigh and try to avoid when writing their code.
Who knows? Perhaps "lockless" algorithms will find some particular use in real-world management problems.
It was in no way clear to the court in the beginning that SCO's case was weak. It was clear to us, but we were technical experts with no small degree of bias. It may have been clear to people in IT departments, but it wasn't have been clear to the people who control company's purse strings.
Cross-licensing agreements have been in place between big names for decades. AMD and Intel have them. Intel was in the habit of making them before AMD existed.
You don't need to worry about the likes of them. If they're large enough to have the need and clout to sign cross-licensing agreements, they're large enough that they can handle patent submariners. Even if they lose their court case and are ordered to pay, they'll go on doing what they were doing anyway; if they didn't expect to make money on it in the first place, they wouldn't have done it. Even if they're ordered to pay settlement fees, they'll still continue to make money.
There was just as much (even more) ambient fear 2-5 years ago as there is today, but it's really not something worth getting in a twist over. You really can't halt something like this, because for every big-name company that backs off, three more are waiting in the shadows to get in on the market.
That's not the precise question. The precise question is, "why does the involvement of corporate lawyers from every major tech company in the world lead things to a standstill with everyone afraid of potential lawsuits for any new development or implementation utilizing FOSS as the starting point?"
Nothing you describe makes developing off of Linux, Android or other open-source or free-software products any more of a risk than it was a year ago, perhaps even two years ago. We've seen this pattern of events before, with SCO, but Linux kept growing. We've seen IP risks come into play with BSD, with AT&T being the plaintiff, but UNIX kept growing.
I have absolutely no doubt that, somewhere, the Linux kernel and/or minimal userland runtime infringes upon patents held by Microsoft, IBM, Intel, AMD, Google and others, but the most you see is Microsoft threatening to pull a trigger they've never dared to in the past. Why? Because the other big names would bring their own patent portfolios to bear on them, because all the big players except Microsoft and Apple heavily depend on Linux, and the world of patents is one giant pile of Mutually Assured Destruction.
The patent sea submariners won't be able to do any more damage than they've ever been able to do, and they're not interested in innovators; innovators are almost invariably too small of fish for them to care about.
Why?
Embrace and extend isn't usually a bad thing, as long as it isn't embrace, extend and don't disallow anyone else from implementing a compatible extension.
The best documentation may be source code, and documenting the extension is a Really Good Thing if you depend on ISVs at all, but even the lack of documentation doesn't make embrace-and-extend a bad thing.
What makes embrace-and-extend a bad thing is disallowance of alternate implementation through general legal mechanisms like anti-reverse-engineering provisions in law, as well as specific legal mechanisms like patents.
This the third time I'll have attempted to post a reply to this. (I don't know where the other two went)
It's not GNOME that will suffer bitrot. GNOME has many users across many distributions. What will suffer bitrot is the glue code that integrates GNOME with Ubuntu core components and behaviors.
Desktop metaphor has been around since the 80s. I don't know when a 'Launcher' button first came around, but it didn't hit Windows until Windows 95/Windows NT4, and I remember it being weird and confusing for those of us who had been accustomed to Win3.1's Program Manager. Even worse was the addition of that 'X' button in the upper-right corner of windows. I closed many applications I hadn't meant to while trying to maximize them.
The "desktop" metaphore has been undergoing changes every few years for as long as it's been around. Personally, I think overlapped windows are a poor deal to begin with, but it's taking mobile devices and limited screen space for more people to notice that.
Microsoft comes out with a new, infuriating rewrite of the desktop every 4-6 years. I really don't think Linux poking around every 2-3 years is going to have a a major offputting effect to people who are new to Linux. It's much more offputting to those of us who have been using Linux on the desktop for over a decade.
Not GNOME, but the bindings and glue that integrate GNOME with Ubuntu. GNOME will see plenty of users and involvement by the nature of it being a widespread project included with many distros. That's not at issue. What's at issue is the glue code that Ubuntu devs write and maintain that integrate GNOME with the Ubuntu in general and specific fashions.
Heh. I suspect a number of DR and armor rules were being misapplied by whoever set up a Spartan-vs-Fallout comparison.
Your argument such degrees of configurability not being for everyone is spot-on, of course. However, I've not found any other distro that handles preserving system configuration alterations as well as Gentoo does. :)
Not GNOME, but GNOME's integration with Ubuntu's system controls. GNOME itself won't see bitrot because, as a unit, GNOME sees a lot of testing. However, the glue code between GNOME and Ubuntu will suffer, as while GNOME will see a lot of users, and Ubuntu will see a lot of users, the combinanation of GNOME+Ubuntu will see fewer users.
No, in that specific case, I was irritated at the lack of command-line workarounds.
You've got me lusting after setting up a 92-machine computer lab as a Gentoo distcc setup.
Gentoo is awful in that it takes a long time to get things just right, but it's awesome that things can be made far more 'just right' than any other distro I've ever used.
There's an analogy to GURPS in there somewhere...
when you can just set it up the way you like.
Except that anything that's not part of the primary feature set or user interaction path on Ubuntu tends to see bitrot, more so than in distros that don't try to tie everything together.
The reason is obvious; Ubuntu devs try very hard to create a unified and convenient experience (and they do, for a large class of users), and that work leads to the creation of code and features that sees a large amount of testing and use for the general case. They don't see a lot of testing for people who don't use the general case. For example, I was forced to switch away from 'wmii' when I discovered that key Ubuntu features didn't function well (or at all) if one didn't have a FreeDesktop.org tray for interacting with some Ubuntu core control mechanisms, and there were no discoverable command-line-driven accessors to those control mechanisms. This general class of problems has hit me every time Ubuntu saw a new six-month-release cycle.
The first response is usually "try an LTS release." LTS releases are nice for fire-and-don't-quite-forget systems and servers, where one can run apt-get update && apt-get-upgrade, but not need to install new packages often, if ever. On a desktop or workstation, or anything where any kind of development needs to be done, even Ubuntu's 3yr release cycle (which kicked Debian's butt when first adhered to) is slow. Proprietary vendors tend to release packages for the latest 6mo release, and the latest LTS if you're lucky.
The second response is usually "check the forums." The forums are (and always have been) a mess whenever one wanted to try something not-really-bleeding edge; often enough one would come across a thread four years out of date after seeing more recent threads referring queries to the "established" thread. In that time, APIs change, and even entire toolchains get deprecated and replaced.
The third response is usually "file bug reports!" or "contribute some changes!" ... I've got friends who are Ubuntu devs or dedicated advocates, and I sometimes hear this from them, too. I don't have the time. Really, I don't. I managed to file three bugs this year. Two against Ekiga, and one against LibreOffice. That's a record for me. I didn't have time to follow up on questions around the Ekiga bugs, and I was fortunate someone else was able to reproduce the LibreOffice bug.
I'm not saying Ubuntu is inherently horrible; at times, it's the best tool for the job. However, I don't think the claim that getting back to tried-and-true is "only a few clicks away" exhibits an awareness of how rapidly non-default configurations on Ubuntu undergo bitrot.
I use Ubuntu only when I need something up and running fast. I use Debian or Gentoo when I need it up and running right. (Often Ubuntu server can stand in for Debian in server circumstances. It depends on whose LTS release has the package/version pairs I need)
Would this be the case in question re Amstrad v Western Digital? Also, the WP article on Amstrad talks about them suing Seagate, which sounds like it might stand correction.
Should you recall the cases in question, a reference would make for interesting educational material. (Even if the tech is a bit outdated, now)
Yeah, someone doesn't understand the difference between a GUI toolkit and a browser. I doubt Gtk+ 3.2 includes a C->HTML5 transcoder.
Anyone want to write a Gaussian Blur filter in ECMAScript, and run it on a four-million-pixel, 4-channel raster image?
I recall not being able to use BSD for the first project I wanted to set up there. That was quite some time ago, though.
Used to be you couldn't use a BSD license on Google Code, but that's apparently changed. My only remaining complaint is that there isn't a good way for me to take a project on Google Code (e.g. "dastoob") and assign a domain to it. I've got dastoob.net set up right now to 301 redirect to the relevant Google Code page.