People who can figure out using two buttons shouldn't be allowed to breath on their own, let alone use a computer. There is getting confused, and then there is just not trying.
To your first point: yes, that is the whole point. Commercial companies in particular require this for their dual OSS/commercial products. Novell Hula, MySQL come to mind quickly..
Second point: Copyright assignment, not transfer.. Though, of course, you did create competition for yourself.
If your goal is to fix a bug in project X, then you may need to do this to have your 1000 line patch accepted. If you want to share that fix/enhancement, getting the upstream to accept and maintain it is likely your best bet, regardless of what license you need to release it under. Up to you, of course, but its not black or white. Very much also dependent on the goals of the patch.
Well, I'd like to see peace on earth, good will towards man, and get a blow job tonight. But none of those things have to do with this article. Well, burning windows may get me a blow job. But only when they work without crashing.
"It must"... VMWare ESX runs on the bare hardware, i.e. no "host" OS. GSX ("Server" now) runs on top of a host OS. Even if it is a very thin, and low overhead layer, the host OS is in the way...
Then use Debian. If you only want bug fixes, Linux is the only logical choice. Will Microsoft support Vista in 15 years? No. Will the source code for the current version of Linux be available in 15 years? Yes.
... More to the point, will Debian answer their phone about $VERSION_NOW in 15 years? Oh, right. Well, at least Novell will answer the phone for 5 years, which is about 2 more then MSFT, and 5 more then Debian.
Well, Gnome is mainly done in the States. Thus the cataclysmic change will be from 20->21. Most jurisdictions in Canada, its 18->19. Have no idea about Europe.. Anyway: not many places left where 17->18 is the mind blowing coming of age experience it once was.
I would disagree. Every system that is running a "general purpose" OS such as Windows or Linux, and that doesn't need direct access to very strange hardware, is ripe for virtualization. Even if you only have on VM per real host. Lets say that VMWare has a 10% overhead.. Buy 10% more hardware!
1 VM per real host still has some advantages. Real hardware upgrades can happen without downtime. Non extreme hardware failures can trigger migration over to another real system, with practically no downtime without clustering, or only minutes to hours of downtime without. You can migrate over to another 1:1 VM:HW system and get the same performance, or to a HW box with other VMs with reduced performance. And for 24-48 hours it takes to get some more hardware, what is better? No server, or reduced performance? Drivers for model XYZ card, or XYZ.2? Neither, drivers for virtual card. Which KVM port is that service on today? None, its on the vmware-console on your desk, like always.
Of course, this all assumes that you are using some network-centric/aware VM system, with the good management tools.
Well, disks may not be a great example. VMWare is of course a product of EMC, which makes (drumroll) high end SAN hardware and software management tools. While Im not quite saying that there is a clear conflict of interest here, the EMC big picture is clear: "now that you have saved a metric shit load of cash on server hardware, spend some of that on a shiny new SAN system". The nicer way of that is that both EMC SANs and VMware do the same thing: consolidation of hardware onto better hardware, abstraction of services provided, finer grained allocation of services, shared overhead - and management.
If spikes on one VM are killing the whole physical host, then you are surely doing something wrong. Perhaps you do need that SAN with very fast disk access. Perhaps you need to schedule migration of VMs from one physical host to another when your report server pegs the hardware. Or, if its an unscheduled spike, you need to have rules that trigger migration if one VM is degrading service to others.
And businesses? Do you really think they'd be stupid enough to pay an ongoing subscription fee when they can just pay it up front and amortize it over the same time period? Uh... no.
Well, perhaps not at $15/month/seat, but at some reasonable number, possibly. And if MS would guaranty/lock-in that price for, say 4+ years, then absolutely. For one, you move a capitol expenditure to a recurring cost. This can be a good idea. Perhaps most importantly, however, is that you get predictability - stability. Cost stability may be worth, I dunno, 30% over an even low risk gamble. ("For the next 5 years, office software costs $10/desktop. We thus only have to think about it again in 4.5 years").
One significant problem MSFT has today is that they have toped out. Their business model has been based around recurring sales every 3-5 years for their various products. Sell, write upgrade with useful/marketable features, sell again, repeat. Most people have no compelling reason to upgrade to Vista (Even if it didn't suck), or to Office $NOW. (admitidly, Im not a heavy office-type user, but what is new/better with Word and Excel since 1998? Seriously.) People slow down from upgrading blindly to every 2nd or 3rd version. Or switching to something that is cheaper, and "good enough" (oo.o coming quickly to mind). MSFT is not stupid and they see the built in problem with this underlying theory of operation. The number of remaining useful/marketable features of an office suite is drying up. Turn your focus from product features, to stability, and technical support. Im not saying that MSFT will opensource their products. But they are looking to take the opensource business model of selling support for their software.
They are hardly trade secrets. Google isn't in the hardware business. There are only so many patterns of disk usage on can have, and knowing what pattern Google has would hardly be useful to figure out how they did anything that they do. At least, to any level of detail useful enough to copy.
The amount of positive press they get from these types of releases easily justifies the effort to polish internal reports up to a publication standard. By releasing these types of papers, others may change their buying habits, which in turn will change the products sold. Google may believe that these types of papers would cause shame, not from individual manufacturers, but the industry in a whole, and thus cause better products to be produced.
You would think so at first. But the reality is that any (very large) general purpose software project, when shipped, will have bugs in it, known to the development (and even management) team(s). It should be stable, and it may even be stable on the H hardware platforms * S software apps it was tested against. But against all possible combinations of real world hardware and software? Lets be realistic here. Let there be no mistake here, I think that Microsoft does a particularly bad job at releasing quality v1 products (and Vista may be enough of a change to be another v1 OS, I don't just mean a v X.0.. but that too), but everyone does a bad job at producing real world solid code.
GPSs can under ideal circumstances accurate down to 30cm. On handheld units, perhaps 10m. So WTF, lets go with that number. Further assume that people never travel faster then 1000km/h, which is about half the speed of a Concorde but still significantly faster then any commercial jet today in service. 1000km/h / 10m = 27.77 hz (maximum relevant data collection cycle) - 3 111.27 cycles/day. Say that they are lazy and they store UTM coordinates as 8 bit strings, thats 15 chars; 15 bits. 32 bit timestamps (which would be stupid, may as well be WTF ever GPS uses), and say 50 chars/bits for some kind of UID, we get 97.... call it 100 bits/user/cycle. Or around 40 kilobytes/day. Say I'm wrong, and off by a factor of 10, and they have no DBAs who know about data encoding. 400 k/day, less then 12mb/month.
12mb/day is nothing, in the grand scheme of things, if "they" were motivated to do it. And assuming that they use a non-brain dead encoding scheme like I have proposed, and only record position if there is movement, then we are likely down to few mb/years. Cycle the data out so we only record ~100m accuracy, every 30 sec/max (fractions of hz), we are down to few mb/lifetime.
Extend your argument. Emanuel got a friend elected by working the system into putting him into a sport that he then timed a leak to make sure race. Simplify. Emanuel got a friend elected by working the system to put him in a sure race.
Wouldn't the same have been true of Foley in the first place? How did he run in a sure race for the Reps? The powers that be don't waist sure races on people they don't know.
Either way, pre scandal, post scandal, the race was a sure thing. They problem then is that races ever become sure things. Why does that happen? Because (in both these cases, at least) the population votes for the party. A color. A letter. Not paying attention to the man. The people are sheep. The are just voting based on an animal logo. They have no will. They are playing themselves.
Well, sure, by your definition "political" doesn't have any meaning, because you have redefined "political" to mean "everything". And, sure, Linus is a political creature, as we all are. But I wasn't talking about the politics of Linus, but of his project. The kernel project hasn't made any significant play into politics, as a group, except perhaps for not holding Kernel summits within the USA (but that too was purely pragmatic. No letters to the US Government, no lobbying efforts. "Fuck it", and do them elsewhere). Last years open letter about GPLv3 went out of its way to say it was only from some of the contributors, not from the project. Individual kernel hackers may care very much about politics, and Linus almost definitely does to. But this doesn't much filter into the code. Individual files are under non-GPLv2 "only" licenses; fairly trivial patches closing out 3rd party modules haven't been included; the barrier to changing APIs is fairly low, but they don't change them randomly just to annoy 3rd party module writers; they allow and ship firmware blobs.
IBM wants to sell hardware and services, and they contribute code to the kernel. HP wants to sell hardware, and they contribute code to the kernel. Oracle wants to sell software, and they contribute code to the kernel. Person X wants freedom and contributes code to the kernel. Person Y is bored and contributes code to the kernel. The kernel is about all of that, and none of that.
The FSF was once the largest and majority contributor to the GNU Project. They produced code, funded others to do so, and they produced political energy. I doubt they any longer contribute the majority, or even the most, code to GNU proper systems. They are definitely not doing (the most) visible stuff like mozilla.org, Debian, OO.o. But Im not here to talk about how many KLOCs of code the FSF is shipping.
Lets put it this way:
FSF expends their efforts on political goals, while shipping code. Hardly ever do they "not care" about a political or legal problem. The Linux Kernel collective spends their efforts on shipping code, while sometimes being involved in politics. They try to care as little as possible about political or legal problems.
Slashdot Mirror
People who can figure out using two buttons shouldn't be allowed to breath on their own, let alone use a computer. There is getting confused, and then there is just not trying.
To your first point: yes, that is the whole point. Commercial companies in particular require this for their dual OSS/commercial products. Novell Hula, MySQL come to mind quickly..
Second point: Copyright assignment, not transfer.. Though, of course, you did create competition for yourself.
If your goal is to fix a bug in project X, then you may need to do this to have your 1000 line patch accepted. If you want to share that fix/enhancement, getting the upstream to accept and maintain it is likely your best bet, regardless of what license you need to release it under. Up to you, of course, but its not black or white. Very much also dependent on the goals of the patch.
Well, I'd like to see peace on earth, good will towards man, and get a blow job tonight. But none of those things have to do with this article. Well, burning windows may get me a blow job. But only when they work without crashing.
"It must"... VMWare ESX runs on the bare hardware, i.e. no "host" OS. GSX ("Server" now) runs on top of a host OS. Even if it is a very thin, and low overhead layer, the host OS is in the way...
Well, vendor supported Solaris is more expensive then vendor supported Linux. And only vendor supported shit gets run in the enterprise.
But, even ignoring that little fact, you seem to be ignoring the T in TCO.
Well, Gnome is mainly done in the States. Thus the cataclysmic change will be from 20->21. Most jurisdictions in Canada, its 18->19. Have no idea about Europe.. Anyway: not many places left where 17->18 is the mind blowing coming of age experience it once was.
Yeah, of course. When doing the install, just tell it not to do so. Or edit /etc/inittab with an editor.
I would disagree. Every system that is running a "general purpose" OS such as Windows or Linux, and that doesn't need direct access to very strange hardware, is ripe for virtualization. Even if you only have on VM per real host. Lets say that VMWare has a 10% overhead.. Buy 10% more hardware!
1 VM per real host still has some advantages. Real hardware upgrades can happen without downtime. Non extreme hardware failures can trigger migration over to another real system, with practically no downtime without clustering, or only minutes to hours of downtime without. You can migrate over to another 1:1 VM:HW system and get the same performance, or to a HW box with other VMs with reduced performance. And for 24-48 hours it takes to get some more hardware, what is better? No server, or reduced performance? Drivers for model XYZ card, or XYZ.2? Neither, drivers for virtual card. Which KVM port is that service on today? None, its on the vmware-console on your desk, like always.
Of course, this all assumes that you are using some network-centric/aware VM system, with the good management tools.
Well, disks may not be a great example. VMWare is of course a product of EMC, which makes (drumroll) high end SAN hardware and software management tools. While Im not quite saying that there is a clear conflict of interest here, the EMC big picture is clear: "now that you have saved a metric shit load of cash on server hardware, spend some of that on a shiny new SAN system". The nicer way of that is that both EMC SANs and VMware do the same thing: consolidation of hardware onto better hardware, abstraction of services provided, finer grained allocation of services, shared overhead - and management.
If spikes on one VM are killing the whole physical host, then you are surely doing something wrong. Perhaps you do need that SAN with very fast disk access. Perhaps you need to schedule migration of VMs from one physical host to another when your report server pegs the hardware. Or, if its an unscheduled spike, you need to have rules that trigger migration if one VM is degrading service to others.
Captain America is dead!
His friend,
Captain Obvious.
If by "In Toronto" you mean "3500km to the west", then yes, X-Files was shot in Toronto.
Checking quickly, your comment just showed up in my /dev/urandom at 74629629165936 blocks of 1k. It may be in there again.
If you think that both SGML and HTML are subsets of XML, its time to go back to set theory class.
Well, perhaps not at $15/month/seat, but at some reasonable number, possibly. And if MS would guaranty/lock-in that price for, say 4+ years, then absolutely. For one, you move a capitol expenditure to a recurring cost. This can be a good idea. Perhaps most importantly, however, is that you get predictability - stability. Cost stability may be worth, I dunno, 30% over an even low risk gamble. ("For the next 5 years, office software costs $10/desktop. We thus only have to think about it again in 4.5 years").
One significant problem MSFT has today is that they have toped out. Their business model has been based around recurring sales every 3-5 years for their various products. Sell, write upgrade with useful/marketable features, sell again, repeat. Most people have no compelling reason to upgrade to Vista (Even if it didn't suck), or to Office $NOW. (admitidly, Im not a heavy office-type user, but what is new/better with Word and Excel since 1998? Seriously.) People slow down from upgrading blindly to every 2nd or 3rd version. Or switching to something that is cheaper, and "good enough" (oo.o coming quickly to mind). MSFT is not stupid and they see the built in problem with this underlying theory of operation. The number of remaining useful/marketable features of an office suite is drying up. Turn your focus from product features, to stability, and technical support. Im not saying that MSFT will opensource their products. But they are looking to take the opensource business model of selling support for their software.
.fuckedbyregisterfly
Scratch harder.
They are hardly trade secrets. Google isn't in the hardware business. There are only so many patterns of disk usage on can have, and knowing what pattern Google has would hardly be useful to figure out how they did anything that they do. At least, to any level of detail useful enough to copy.
The amount of positive press they get from these types of releases easily justifies the effort to polish internal reports up to a publication standard. By releasing these types of papers, others may change their buying habits, which in turn will change the products sold. Google may believe that these types of papers would cause shame, not from individual manufacturers, but the industry in a whole, and thus cause better products to be produced.
It is, after all, a dot-com.
You would think so at first. But the reality is that any (very large) general purpose software project, when shipped, will have bugs in it, known to the development (and even management) team(s). It should be stable, and it may even be stable on the H hardware platforms * S software apps it was tested against. But against all possible combinations of real world hardware and software? Lets be realistic here. Let there be no mistake here, I think that Microsoft does a particularly bad job at releasing quality v1 products (and Vista may be enough of a change to be another v1 OS, I don't just mean a v X.0.. but that too), but everyone does a bad job at producing real world solid code.
GPSs can under ideal circumstances accurate down to 30cm. On handheld units, perhaps 10m. So WTF, lets go with that number. Further assume that people never travel faster then 1000km/h, which is about half the speed of a Concorde but still significantly faster then any commercial jet today in service. 1000km/h / 10m = 27.77 hz (maximum relevant data collection cycle) - 3 111.27 cycles/day. Say that they are lazy and they store UTM coordinates as 8 bit strings, thats 15 chars; 15 bits. 32 bit timestamps (which would be stupid, may as well be WTF ever GPS uses), and say 50 chars/bits for some kind of UID, we get 97.... call it 100 bits/user/cycle. Or around 40 kilobytes/day. Say I'm wrong, and off by a factor of 10, and they have no DBAs who know about data encoding. 400 k/day, less then 12mb/month.
12mb/day is nothing, in the grand scheme of things, if "they" were motivated to do it. And assuming that they use a non-brain dead encoding scheme like I have proposed, and only record position if there is movement, then we are likely down to few mb/years. Cycle the data out so we only record ~100m accuracy, every 30 sec/max (fractions of hz), we are down to few mb/lifetime.
Or perhaps it has just taken until a year ago for everyone you know to realize that you are a total prick.
Extend your argument. Emanuel got a friend elected by working the system into putting him into a sport that he then timed a leak to make sure race. Simplify. Emanuel got a friend elected by working the system to put him in a sure race.
Wouldn't the same have been true of Foley in the first place? How did he run in a sure race for the Reps? The powers that be don't waist sure races on people they don't know.
Either way, pre scandal, post scandal, the race was a sure thing. They problem then is that races ever become sure things. Why does that happen? Because (in both these cases, at least) the population votes for the party. A color. A letter. Not paying attention to the man. The people are sheep. The are just voting based on an animal logo. They have no will. They are playing themselves.
It would be trivial to build a ruler that is exactly pi. The problem would be that if you do so, you would break all the other rulers out there.
Well, sure, by your definition "political" doesn't have any meaning, because you have redefined "political" to mean "everything". And, sure, Linus is a political creature, as we all are. But I wasn't talking about the politics of Linus, but of his project. The kernel project hasn't made any significant play into politics, as a group, except perhaps for not holding Kernel summits within the USA (but that too was purely pragmatic. No letters to the US Government, no lobbying efforts. "Fuck it", and do them elsewhere). Last years open letter about GPLv3 went out of its way to say it was only from some of the contributors, not from the project. Individual kernel hackers may care very much about politics, and Linus almost definitely does to. But this doesn't much filter into the code. Individual files are under non-GPLv2 "only" licenses; fairly trivial patches closing out 3rd party modules haven't been included; the barrier to changing APIs is fairly low, but they don't change them randomly just to annoy 3rd party module writers; they allow and ship firmware blobs.
IBM wants to sell hardware and services, and they contribute code to the kernel. HP wants to sell hardware, and they contribute code to the kernel. Oracle wants to sell software, and they contribute code to the kernel. Person X wants freedom and contributes code to the kernel. Person Y is bored and contributes code to the kernel. The kernel is about all of that, and none of that.
The FSF was once the largest and majority contributor to the GNU Project. They produced code, funded others to do so, and they produced political energy. I doubt they any longer contribute the majority, or even the most, code to GNU proper systems. They are definitely not doing (the most) visible stuff like mozilla.org, Debian, OO.o. But Im not here to talk about how many KLOCs of code the FSF is shipping.
Lets put it this way:
FSF expends their efforts on political goals, while shipping code. Hardly ever do they "not care" about a political or legal problem.
The Linux Kernel collective spends their efforts on shipping code, while sometimes being involved in politics. They try to care as little as possible about political or legal problems.
Better?