Nobody is stopping you from doing whatever you want with your device that you own. Hack it up, replace the UEFI, overclock it, replace the processor, throw it in the river, do whatever you want. It's your device. But NOBODY is required to make it EASY for you to modify the device to your liking, or to make it easy for you to use the device in a manner other than as sold.
Of course nobody is required to make general-purpose computers easy to modify -- but the market can, and should, reject efforts to make hardware unnecessarily difficult to modify and reuse.
That's what the crowd is doing here: We're part of the market, and we're trying to reach consensus on what we will and won't accept as buyers willing and able to act of our own free will.
Sorry, but if you have access to Bombs you are NOT a civilian.
So a high school chemistry set is all I need to become an enemy of the state? The uncle who lost a few fingers messing around in the garage as a kid, not a civilian?
Again: If you work daily and pay your bills you are a civilian...
And if I'm unemployed, that makes me a combatant? Really?
Think for a minute about the things that come out of your mouth.
Couldn't tell if this was joking -- doesn't really translate over text -- so I'm taking the question as serious.
Of course not. If I can't convert it immediately and directly to cash, it's only as cash-equivalent as what it saves me -- and I can cook for myself cheaply (measured in time as well as money -- pressure cooking means a simple chicken-and-potatoes dinner is all of 15 minutes), or rely on the spouse (who used to own a catering company) for fantastic food if she's not putting in too many hours herself.
That said -- my current employer does cater breakfast and lunch, and I will admit that it's convenient. That convenience doesn't translate into being able to pay off the mortgage, however, and the cash component is not a thing to forget easily. Did my time at penniless startups and enjoyed it greatly, but that's a game for the young; I'm older and more risk-adverse these days.
Huh??? From what I have heard, Google's pay is by far the best in the 'Valley, both cash only and total (including stock/benefits). That said, you're not going to get rich working for either them or Yahoo. You only make it big here by lucking into an employee-number-[2..20] role.
That's, err, very out-of-line with what I've heard, and I've had friends there only a few years ago -- word was that the total comp was healthy (after you considered everything they spent on you -- a great deal of which wasn't in any way cash-equivalent), but the cash comp not at all.
That said, every time I've been in their interviewing pipeline (three times now, I think?), I ended up accepting a job somewhere else before we got to the point of salary negotiation, so my impressions are distinctly secondhand (not third- or fourth-hand, mind you).
I wouldn't be so sure of that. Google may be a big name that looks good on a resume, but their payscales (ya know, actual cash compensation, the type that pays a mortgage) are crap.
Those are all pretty core features-- to my mind, ESPECIALLY the disk and NIC hot add. There are a lot of times that it is an absolute blessing to be able to roll out a new VLAN on the network and to just hot-add a NIC to the firewall VM on that VLAN, and your network suffers no outage. With disk, its awfully nice to be able to add a USB disk to the VM without having to reboot the entire thing (again, how does HyperV and RHEV not have this?).
I can't speak to RHEV -- I ran on bare KVM. RHEV eliminated any feature from KVM that Red Hat didn't consider rock-solid enterprise-ready, effectively paring it down to the featureset they were willing to thoroughly test on all supported hardware.
All four of the items you listed were present and usable in upstream KVM back when I was working with it years ago, except for storage migration (which had just been implemented and was still at a place where I wanted to see other folks using it before I wanted to trust it myself... plus, already had shared storage anyhow and didn't need it).
I've been playing Aralon on my Xoom lately and I love it.
Bloody shame it's Amazon-exclusive; My first experience with their "app store" left me utterly unwilling to have any further part in it (Log into Amazon every so often to keep playing things I've purchased? Not going to happen), nor to pirate it, so that leaves me waiting for the developer to release on Google Play.
VMWare is pretty widely recognized as the king of virtualization-- at least so long as you arent concerned with money. Its overhead is far far smaller than the others especially when dealing with huge numbers of connections, and it simply has more features than its competitors.
Which doesn't mean those features are implemented well.
Not so long ago, I built an automated QA platform on top of Qumranet's KVM. Partway through the project, my employer was bought by Dell, a VMware licensee. As such, we ended up putting software through automated testing on VMware, manual testing on Xen (legacy environment, pre-acquisition), and deployment to a mix of real hardware and VMware.
In terms of accurate hardware implementation, KVM kicked the crap out of what VMware (ESX) shipped with at the time. We had software break because VMware didn't implement some very common SCSI mode pages (which the real hardware and QEMU both did), we had software break because of funkiness in their PXE implementation, and we otherwise just plain had software *break*. I sometimes hit a bug in the QEMU layer KVM uses for hardware emulation, but when those happened, I could fix it myself half the time, and get good support from the dev team and mailing list otherwise. With VMware, I just had to wait and hope that they'd eventually get around to it in some future release.
Sure, but how do you prove that it is written from scratch, especially when there would need to be a high degree of similarity when describing the same item? For example, a job ad is going to contain a list of qualifications -- how are you going to advertise the same job without copying the list of qualifications?
Only the expressive elements, not the functional/utilitarian ones, are subject to copyright -- so the necessary similarity doesn't count against you in a copyright case, and highly functional language is by nature less protected.
Except that now the $130 food processor does NOT "last a few more years" it just has a better brand name and/or a few more features but dies just as quickly. Hell between the crap soldier and the making every damned thing out of plastic that $1000 laptop doesn't last a damned bit longer than the $450 as the fans are just as crappy, the heatsinks just as thin, again they complete on brand or feature NOT on durability.
On the other hand, if you compare today's $200 full-page scanner with the $3000 scanner of the late 1990s -- the latter was built like a tank, considerably more so than even the $3000 scanner of today.
Complaining about how things that used to be built to last are being built to be cheap today doesn't mean that expensive things today are built with the durability of expensive things of yesteryear.
Apple was VERY STRAIGHTFORWARD on the fact that they had patented the iPhone
"patented the iPhone"? What does that even mean? Patents protect processes, not devices or objects.
Except design patents, yes, but frankly, those aren't what most people think of when someone says "patent". Saying that you "patented" a device with hundreds of thousands of parts (once the software is taken into account) is uselessly vague; the declaration has nothing "straightforward" about it at all.
Until Android stops being a fragmentation fuckfest, it's always going to be the platform of choice for poor people, hackers, and freeloaders. That's not a market that matters to a business.
Speaking as a committed Android user (and occasional developer), this is perfectly fine.
I'm part of the "freeloader" category (have money, hate spending it), and... well, I don't care if the newest shiniest paid app isn't available, because I wouldn't be buying it anyhow! So -- it's perfectly fine if companies building paid apps focus primarily on iOS; go on, do that, make a profit, best of luck to 'ya. The 3rd-party apps I use are mostly free-of-charge (banking integration -- why would a bank care only about customers who are good little consumers, when they make their money off interest from re-lending savings?) or things that iOS doesn't support anyhow (3rd-party keyboards), and... well, they're obviously available today.
Moreover, there are business categories in which the "poor people, hackers, and freeloaders" are the bulk of one's market. Take the example of a job search site. Guess what? Unemployed people are a core part of our target demographic. So are "poor people" (unlike some of our competitors who focus only on high-end jobs). So are hackers (being part of that high-end talent market that we don't focus on exclusively, but do play in). Android as a platform matters to us.
True, the Chinese no-name tablets sucked, as did things like the Archos 7 Home Tablet, but what sucks about the Kindle Fire? I see the Nexus 7 as a more direct replacement for the Kindle Fire.
My girlfriend has a Kindle Fire, and loves it -- but their decision not to participate in the ecosystem was a deal-breaker for me: If I buy an Android application, I want it to show up on all my devices (without being dependent on rootability and availability of 3rd-party firmware). Amazon's decision not to play nice with Google, and thus not to get access to the Market (now Google Play) meant that they might as well be an iDevice to users with preexisting investment (or intent to invest in the future) in Android-ecosystem apps.
They also are still in love with faxing things, they live in the 70's.
Probably for the same reason doctors use fax machines for sending prescriptions and patient data around but not email.
Faxes have a legal presumption of security, and intercepting them (specifically!) is a crime with fairly stiff penalties... whereas sending something around by unencrypted email means you're liable if it leaks.
Your commute may be fine, but can I join you on your next cross-country vacation? Recharging every 160 miles should be entertaining.
Dunno 'bout you, but when I'm going on a long-distance vacation, I fly and then rent. Driving cross country seems like a whole lot of miserable hours (half of them -- if going to northern California -- spent just reaching the Texas border), not to mention the expense. Why would you voluntarily do such a thing?
However there was a trade-off. With Automobiles we needed a smoother road infrastructure, that cost tax payers a lot of money.
One point of correction -- the move towards higher standards for road construction was actually started in the 1890s by the Good Roads Movement, a project of the League of American Wheelmen -- the organization which still exists today as the League of American Bicyclists. It was this that resulted in the Office of Road Inquiry (federally funding research into road construction), which later became the Federal Highway Administration.
If patents no longer promote progress... can they be ruled unconstitutional?
There was hope for that, but the holding in Eldred v. Ashcroft pretty much ruled it out. The effect of that holding (made in the light of a great deal of evidence to the effect that the CTEA did not promote "progress and the useful arts" in any meaningful way) was to find that the clause in question (though this case applied to copyright) was effectively meaningless preamble, not binding on Congress's lawmaking ability.
"No more purposefully buggy DSDT tables, no more half-hearted Linux support"
Is it purposeful on the OEM's part? I mean, if they're using Microsoft's AML compiler rather than Intel's, that pretty much gets them there regardless.
Did you seriously just say VisualStudio sucks[...]
No, I didn't say Visual Studio sucks. Go read my post again -- this time, paying attention only to the things I actually said and not whatever hyperbole you happen to feel like adding.
Keep in mind, I was responding to someone whose claim wasn't "doesn't suck"; the claim was general-purpose superiority. (Moreover -- I don't doubt that someone could write a LISP mode with SLIME-equivalent support, but until such a thing exists, that still doesn't make VS the superior environment for folks working in LISP).
The more someone implies that one language is the way to go or one style is the way to go for a certain task, the less likely it is that you should believe them.
Obvious Troll is obvious. Or at least, I hope you're trolling, as opposed to trying to look wise by displaying intentional naivete. If you'd left out "for a certain task", I'd agree with you wholeheartedly -- there's no one right tool for every job -- but certainly some tools are better for some jobs than others.
Case in point: At my last job (actually, N-2), a stream processing system that needed to be massively parallel was first developed in Python. It scaled poorly to highly parallel architectures (where it was intended to be deployed), was rewritten in Clojure using the native concurrency primitives, and thereafter scaled linearly to the workload.
Python really was a bad tool for that job -- the primary (CPython) runtime having a big lock everywhere meant that trying to scale cleanly required using a less-common runtime or eating the overhead of the multiprocessing module, and its native types being mutable meant that sharing references to them between threads was dangerous. Clojure really was an exceptionally good tool for that job -- its transactional memory system meant that you could have a large number of threads working in parallel on a problem, and still be able to get a consistent snapshot of the world without needing to freeze any of them by grabbing a lock.
Would other tools have worked well for that task also? Certainly -- Scala would have many of the same benefits, to pick the first example that comes to mind -- but the claim that every language is of about equal utility towards every task fails even to a first approximation.
A pure functional language is one that just relies on recursion with only parameter variables to carry out loops. [...] To me, pure functional just seems to be a very quick way to obfuscate even the simplest potential solutions to a problem.
Or am I missing something profound?
Yes, you're missing something profound.
The big deal (and it's a Really Big Deal) in functional programming is isolation of side-effects. Pure functions transform inputs to outputs, and do nothing else: They don't mutate data, they don't grab locks, they don't interact with I/O subsystems, they don't... well, do anything that isn't interacting with that function's inputs and outputs, and their results are always 100% reproducible (same inputs -> same outputs).
This means that huge sets of problems simply can't exist in parts of your codebase written to be purely functional, and that the parts of your codebase that do IO or similar things are isolated in well-defined locations, nice and far away from the highly testable business logic. It means that pure functions can always be executed in parallel, no locking required. It means that compilers can do all kinds of optimizations which would be utterly unthinkable in less-constrained languages (Example: Calling a pure function twice with the same arguments? It can't have side effects or return a different value for the second call, so the compiler can always just cache the return value from the first call and use it twice).
Recursion isn't really what it's about at all -- the tendency to use tail-call optimization for loops is a minor side effect of the use of immutable data, and it's that decision to use immutable data that makes the huge difference.
Heh, consider what this description says about clojures simplicity: "Leiningen is for automating Clojure projects without setting your hair on fire."
Keep in mind that Clojure users could use Ant or Maven or Grails for their build system, and all of those work perfectly fine; Leiningen, on the other hand, is simpler than any of them.
Clojure developers have a high bar for simplicity, albeit measured in a way that might not make much sense to anyone who doesn't first grok LISP.
Slashdot Mirror
Of course nobody is required to make general-purpose computers easy to modify -- but the market can, and should, reject efforts to make hardware unnecessarily difficult to modify and reuse.
That's what the crowd is doing here: We're part of the market, and we're trying to reach consensus on what we will and won't accept as buyers willing and able to act of our own free will.
So a high school chemistry set is all I need to become an enemy of the state? The uncle who lost a few fingers messing around in the garage as a kid, not a civilian?
And if I'm unemployed, that makes me a combatant? Really?
Think for a minute about the things that come out of your mouth.
Don Knuth comes pretty close to being a living existence proof.
Granted, there's only one of him.
Couldn't tell if this was joking -- doesn't really translate over text -- so I'm taking the question as serious.
Of course not. If I can't convert it immediately and directly to cash, it's only as cash-equivalent as what it saves me -- and I can cook for myself cheaply (measured in time as well as money -- pressure cooking means a simple chicken-and-potatoes dinner is all of 15 minutes), or rely on the spouse (who used to own a catering company) for fantastic food if she's not putting in too many hours herself.
That said -- my current employer does cater breakfast and lunch, and I will admit that it's convenient. That convenience doesn't translate into being able to pay off the mortgage, however, and the cash component is not a thing to forget easily. Did my time at penniless startups and enjoyed it greatly, but that's a game for the young; I'm older and more risk-adverse these days.
That's, err, very out-of-line with what I've heard, and I've had friends there only a few years ago -- word was that the total comp was healthy (after you considered everything they spent on you -- a great deal of which wasn't in any way cash-equivalent), but the cash comp not at all.
That said, every time I've been in their interviewing pipeline (three times now, I think?), I ended up accepting a job somewhere else before we got to the point of salary negotiation, so my impressions are distinctly secondhand (not third- or fourth-hand, mind you).
I wouldn't be so sure of that. Google may be a big name that looks good on a resume, but their payscales (ya know, actual cash compensation, the type that pays a mortgage) are crap.
I can't speak to RHEV -- I ran on bare KVM. RHEV eliminated any feature from KVM that Red Hat didn't consider rock-solid enterprise-ready, effectively paring it down to the featureset they were willing to thoroughly test on all supported hardware.
All four of the items you listed were present and usable in upstream KVM back when I was working with it years ago, except for storage migration (which had just been implemented and was still at a place where I wanted to see other folks using it before I wanted to trust it myself... plus, already had shared storage anyhow and didn't need it).
Bloody shame it's Amazon-exclusive; My first experience with their "app store" left me utterly unwilling to have any further part in it (Log into Amazon every so often to keep playing things I've purchased? Not going to happen), nor to pirate it, so that leaves me waiting for the developer to release on Google Play.
Which doesn't mean those features are implemented well.
Not so long ago, I built an automated QA platform on top of Qumranet's KVM. Partway through the project, my employer was bought by Dell, a VMware licensee. As such, we ended up putting software through automated testing on VMware, manual testing on Xen (legacy environment, pre-acquisition), and deployment to a mix of real hardware and VMware.
In terms of accurate hardware implementation, KVM kicked the crap out of what VMware (ESX) shipped with at the time. We had software break because VMware didn't implement some very common SCSI mode pages (which the real hardware and QEMU both did), we had software break because of funkiness in their PXE implementation, and we otherwise just plain had software *break*. I sometimes hit a bug in the QEMU layer KVM uses for hardware emulation, but when those happened, I could fix it myself half the time, and get good support from the dev team and mailing list otherwise. With VMware, I just had to wait and hope that they'd eventually get around to it in some future release.
"King of virtualization"? Bah.
Only the expressive elements, not the functional/utilitarian ones, are subject to copyright -- so the necessary similarity doesn't count against you in a copyright case, and highly functional language is by nature less protected.
On the other hand, if you compare today's $200 full-page scanner with the $3000 scanner of the late 1990s -- the latter was built like a tank, considerably more so than even the $3000 scanner of today.
Complaining about how things that used to be built to last are being built to be cheap today doesn't mean that expensive things today are built with the durability of expensive things of yesteryear.
"patented the iPhone"? What does that even mean? Patents protect processes, not devices or objects.
Except design patents, yes, but frankly, those aren't what most people think of when someone says "patent". Saying that you "patented" a device with hundreds of thousands of parts (once the software is taken into account) is uselessly vague; the declaration has nothing "straightforward" about it at all.
Unless you believe Larry Goldfarb committed perjury, it's clear that Microsoft had a hand in arranging SCO's funding in a bigger way than merely buying licenses to patents SCO didn't own.
Speaking as a committed Android user (and occasional developer), this is perfectly fine.
I'm part of the "freeloader" category (have money, hate spending it), and... well, I don't care if the newest shiniest paid app isn't available, because I wouldn't be buying it anyhow! So -- it's perfectly fine if companies building paid apps focus primarily on iOS; go on, do that, make a profit, best of luck to 'ya. The 3rd-party apps I use are mostly free-of-charge (banking integration -- why would a bank care only about customers who are good little consumers, when they make their money off interest from re-lending savings?) or things that iOS doesn't support anyhow (3rd-party keyboards), and... well, they're obviously available today.
Moreover, there are business categories in which the "poor people, hackers, and freeloaders" are the bulk of one's market. Take the example of a job search site. Guess what? Unemployed people are a core part of our target demographic. So are "poor people" (unlike some of our competitors who focus only on high-end jobs). So are hackers (being part of that high-end talent market that we don't focus on exclusively, but do play in). Android as a platform matters to us.
My girlfriend has a Kindle Fire, and loves it -- but their decision not to participate in the ecosystem was a deal-breaker for me: If I buy an Android application, I want it to show up on all my devices (without being dependent on rootability and availability of 3rd-party firmware). Amazon's decision not to play nice with Google, and thus not to get access to the Market (now Google Play) meant that they might as well be an iDevice to users with preexisting investment (or intent to invest in the future) in Android-ecosystem apps.
Probably for the same reason doctors use fax machines for sending prescriptions and patient data around but not email.
Faxes have a legal presumption of security, and intercepting them (specifically!) is a crime with fairly stiff penalties... whereas sending something around by unencrypted email means you're liable if it leaks.
Dunno 'bout you, but when I'm going on a long-distance vacation, I fly and then rent. Driving cross country seems like a whole lot of miserable hours (half of them -- if going to northern California -- spent just reaching the Texas border), not to mention the expense. Why would you voluntarily do such a thing?
One point of correction -- the move towards higher standards for road construction was actually started in the 1890s by the Good Roads Movement, a project of the League of American Wheelmen -- the organization which still exists today as the League of American Bicyclists. It was this that resulted in the Office of Road Inquiry (federally funding research into road construction), which later became the Federal Highway Administration.
There was hope for that, but the holding in Eldred v. Ashcroft pretty much ruled it out. The effect of that holding (made in the light of a great deal of evidence to the effect that the CTEA did not promote "progress and the useful arts" in any meaningful way) was to find that the clause in question (though this case applied to copyright) was effectively meaningless preamble, not binding on Congress's lawmaking ability.
Is it purposeful on the OEM's part? I mean, if they're using Microsoft's AML compiler rather than Intel's, that pretty much gets them there regardless.
Those surfaces are insanely bloody expensive to keep up -- and the myth that they're paid for by use fees is just that, a myth.
No, I didn't say Visual Studio sucks. Go read my post again -- this time, paying attention only to the things I actually said and not whatever hyperbole you happen to feel like adding.
Keep in mind, I was responding to someone whose claim wasn't "doesn't suck"; the claim was general-purpose superiority. (Moreover -- I don't doubt that someone could write a LISP mode with SLIME-equivalent support, but until such a thing exists, that still doesn't make VS the superior environment for folks working in LISP).
Obvious Troll is obvious. Or at least, I hope you're trolling, as opposed to trying to look wise by displaying intentional naivete. If you'd left out "for a certain task", I'd agree with you wholeheartedly -- there's no one right tool for every job -- but certainly some tools are better for some jobs than others.
Case in point: At my last job (actually, N-2), a stream processing system that needed to be massively parallel was first developed in Python. It scaled poorly to highly parallel architectures (where it was intended to be deployed), was rewritten in Clojure using the native concurrency primitives, and thereafter scaled linearly to the workload.
Python really was a bad tool for that job -- the primary (CPython) runtime having a big lock everywhere meant that trying to scale cleanly required using a less-common runtime or eating the overhead of the multiprocessing module, and its native types being mutable meant that sharing references to them between threads was dangerous. Clojure really was an exceptionally good tool for that job -- its transactional memory system meant that you could have a large number of threads working in parallel on a problem, and still be able to get a consistent snapshot of the world without needing to freeze any of them by grabbing a lock.
Would other tools have worked well for that task also? Certainly -- Scala would have many of the same benefits, to pick the first example that comes to mind -- but the claim that every language is of about equal utility towards every task fails even to a first approximation.
Yes, you're missing something profound.
The big deal (and it's a Really Big Deal) in functional programming is isolation of side-effects. Pure functions transform inputs to outputs, and do nothing else: They don't mutate data, they don't grab locks, they don't interact with I/O subsystems, they don't... well, do anything that isn't interacting with that function's inputs and outputs, and their results are always 100% reproducible (same inputs -> same outputs).
This means that huge sets of problems simply can't exist in parts of your codebase written to be purely functional, and that the parts of your codebase that do IO or similar things are isolated in well-defined locations, nice and far away from the highly testable business logic. It means that pure functions can always be executed in parallel, no locking required. It means that compilers can do all kinds of optimizations which would be utterly unthinkable in less-constrained languages (Example: Calling a pure function twice with the same arguments? It can't have side effects or return a different value for the second call, so the compiler can always just cache the return value from the first call and use it twice).
Recursion isn't really what it's about at all -- the tendency to use tail-call optimization for loops is a minor side effect of the use of immutable data, and it's that decision to use immutable data that makes the huge difference.
Keep in mind that Clojure users could use Ant or Maven or Grails for their build system, and all of those work perfectly fine; Leiningen, on the other hand, is simpler than any of them.
Clojure developers have a high bar for simplicity, albeit measured in a way that might not make much sense to anyone who doesn't first grok LISP.