What's new is all the high-level stuff done with it: having an internet that not only connects universities, but is accessible by everyone from their home or their mobile phone. Buying stuff on the internet, communicating with each other on Facebook, etc. The thing that's changed is who uses this technology, and what they use it for.
I think you guys are having a very productive discussion right here.
I'll toss in something that I occasionally think about, that's related to what both of you are saying: the design of the operating systems in common use for personal computers. The kernels for Linux, OS X and Windows XP are all basically server technology that has been pressed to serve for desktop use. For example, all of them have been designed to maximize system throughput with techniques that increase end-user latency, like swap.
For example, the OS X Dock has a feature that magnifies the size of the icons as you mouse over them. However, when an OS X system faces memory pressure, the kernel will swap out pages that are in use by the Dock. When this happens, you get a pause of a few seconds between mousing over an icon and the computer magnifying it. The Dock is an element that is always present in the OS X user interface, but the kernel apparently doesn't know about that, and treats it as just another application that can be paged out to speed up something else. And more simply, switching to an application that's been unused for a while is often not just slow, but sluggish; it's not that the application takes a long time initially to perform the commands, it's that the application takes a long time to even respond to user input in the most basic ways.
An OS designed from scratch for personal computing would look quite different from what we have now. There would be a lot more emphasis on real-time response to user input. That's not what we've gotten. What we've gotten is, at best, hacks on top of timesharing server operating system kernels to make them less bad at interacting with the user.
Easy example: PostgreSQL doesn't have native materialized views, whereas SQL Server does have a materialized view implementation, which they call "indexed views." SQL Server indexed views are updated automatically on commits to the base tables of the view, so they're never out of date (unlike Oracle materialized views, for which the automatic updates on commit are an optional feature).
There are a bunch of articles online about how to simulate materialized views in PostgreSQL using tables and triggers, so you might argue that with a bunch of extra work, you could simulate most of what SQL Server is doing. However, there's more! SQL Server's query planner is capable of rewriting a query against the base tables to use an indexed view when appropriate. This means that you can, for example, speed up frequent queries that perform costly grouping and aggregation by creating an indexed view that precomputes the aggregate, without changing your query or application at all. This is impossible to reproduce in PostgreSQL; you'd have to change the application query to use the fake materialized view that you worked hard to create.
The list of things like this goes on and on. PostgreSQL is a decent database, especially given the fact that it's free as in speech; none of this is a discredit against it. But it's simply outclassed by SQL Server.
It means if a few weeks ago, someone would have had to pay $70 billion for hardware capable of decrypting your message within 600 days guaranteed (with an expected success time at the 300-day mark), now they only have to pay $136 million, obviously no big change.
That is true in exactly the same way it is true that if it had rained during my walk yesterday, I would have gotten soaked.
Not one of these features is remotely compelling enough to switch an existing, working app from MySQL.
Sure, let's grant that, for the sake of argument (though I'd say that most of the time it is true). Now, why do people keep developing new applications to use MySQL?
I can never get a good answer to this question. The answers I tend to get are of the form "because they don't want to spend the time to learn a new RDBMS." These people tend to spend a lot of time cleaning up after MySQL's flaws on applications that they inherited, too.
You have given what is, I believe, the most common reason for not switching: MySQL works well enough for what you need so it doesn't make sense to expend additional time and effort (you probably don't have much of the former) to learn something that you will only use for the same purposes. It makes sense.
There are two versions of this argument:
The version that applies to a system that already exists, and has been developed with MySQL.
The version that applies to a system that has yet to be built.
I can buy the argument in case (1), but not in case (2). In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.
None of those sound like a big problem for the authorities. Just make the GPS unit in the cars record your trajectory. Nearly all of the time it will be possible to tell whether you were on the fast road or on the slow one by the path you took before and after the apparent speeding.
SQL Server has always been a decent database. Going to PostgreSQL would probably be a downgrade. Though if I have to say one thing, it would be this: SQL Server 2005 is a lot better in my experience than 2000.
I think the ranchers oppose having their animals chipped because then it becomes too easy for the government to abuse its power and round their cattle up like cattle.
And everyone who had put money in those banks, trusting that the SEC and Fed would make sure those banks couldn't fuck them over should've just be thrown to the wolves? "Bankruptcy" at this level has nothing whatsoever to do with "taking your responsibility"; if your downfall means you'll be taking 200.000 others with you, your rhetoric about "the market decides what's fair" notwithstanding.
You're failing to understand precisely what "bankruptcy" means. Fundamentally, it means wiping out the shareholders of the corporations. Whether we bankrupt the banks is completely severable from whether we guarantee their customers' balances.
The better thing to do, IMO, would have been along similar lines to what FiloEleven says, but more moderate: nationalize the banks (which wipes out the shareholders) with a time cap on how long the government is allowed to own them, inject capital into them, guarantee whichever of the banks' obligations are deemed to be essential (first on the list: deposits), and then sell the banks. Result: depositors don't lose money, bank shareholders are wiped out as punishment for investing on a crappily run bank.
What we did, though, was to rescue everybody, including the shareholders. But the shareholders are precisely the folks that you should not be rescuing.
Yet people still come from around the world and pop across the border from your beloved Canada to seek treatment in the US, because it's the best in the world.
The message before today was, "and if you get caught, you get 3-10 years, then you're back out and you'll be rich."
Unlikely. Even if you got 3-10 years, the damages from the civil lawsuits against you would clean up. Your life might not be ruined, but for somebody like Madoff, he'd end up worse than he started.
So this quote doesn't fully address the One True Controller debate, but I think it's important to realize that we were all children when this equipment came out and we may have a bad case of rose-colored glasses.
Indeed. My family had an Atari 2600 when I was a kid, but we never had a NES. I hate those NES pads. And the world hates me, because DSLR cameras now have those.
Android just won't catch up with iPhone
on
Unlocking Android
·
· Score: 4, Insightful
The iPhone is winning on the basis of having a much superior interface. Open source development has always been notably bad at user interfaces, and more generally, at design; it is no accident that the most successful open source projects are all clones of some other software, or implementations of back-end protocols like HTTP. Very often superior clones, mind you, but it's still derivative.
I may be wrong here, but my understanding is that you need to do significant editorial work, such as abridgement or re-organization, to a work in order to get a new copyright on it.
IANAL, but I think you're overestimating how much work one needs to do in order to get copyright on an edited version. I'm pretty sure if you renumber the pages and add an index to a public domain work, your edition qualifies for copyright protection. Same thing if you add some notes at the beginning, or add footnotes annotating the text, or hell, even if you create a new cover for the book. I would not be surprised if going through the old editions and fixing typos qualifies.
Note that the author in TFA was very careful to describe the product of a lot of these small presses as "facsimiles," and not "editions." That's a very crucial distinction there. A facsimile would be something like a photocopy or straight reprint of an old edition, and something that does not qualify for copyright protection.
The cellphone method works great and has never bothered me until I had to enter a 63-character WPA key into an iPhone.
That sounds like an oversight on Apple's part. In the desktop versions of OS X, the fields for wireless keys have a checkbox to unmask them, so we do know they've gotten it right in at least one product.
I don't think the proposal is to make it a difference. I think the proposal is to have password entry widgets have a little checkbox to control whether the text in them is masked, and have it default to unmasked. Whether you need masking or not is a case-by-case decision.
And, surprise, that's exactly what TFA recommends! Quote:
Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they're using an Internet cafe. It's therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there's a tension between security and usability, sometimes security should win.
Deliberate untruths are lies, but not all lies are deliberate untruths. The most effective lies tend to be composed of nothing but true statements; the lie in that case consists of the deliberate omission of crucial information that the liar knows, in the expectation that the hearer will reach a desired false conclusion. The thing that makes those lies the "best" is that they're verifyable; if your victim takes care to check whether what you actually said is true, they will find that indeed it is, and that will reinforce the conclusion you want them to reach.
Nonsense. The rights of shareholders of a corporation to be informed about materially relevant information about the enterprise do not in general override the privacy rights of its CEO, only in very specific instances (e.g., the CEO is forced to disclose his transactions on company stock, and other dealings with the corporations such as pay and benefits). The possibility that the CEO of a corporation you're investing in is secretly very sick and will die soon is, well, just a risk that you have to take.
The greater depth of field of the GH1 is by no means a disadvantage. The idea that a camera like the GH1 is somehow crippled because it's DOF is wider is just an internets camera measurebator myth. The lenses needed for a sensor of the size of the GH1's are large enough to produce perfectly fine background blur, and you'll get more of your subject in focus thanks to the greater DOF. The larger sensor cameras shallower depth of field is in nearly every case a disadvantage, though one that they make up for thanks to having much larger sensors (and thus allowing you stop down the aperture and crank up the ISO).
There's only one control wheel, but it's pretty simple: one button that's easy to find (right by the shutter) for exposure compensation, another easy-to-find button for ISO, and just turn the wheel by itself for aperture. Pushing a button for exposure compensation isn't a problem, since you push that button with the finger that rests on the shutter.
A lot of us can't ever press the correct button for all of this stuff without looking, given that they're all (a) tiny little buttons that (b) feel the same and (c) don't give you enough tactile feedback that you've pushed them, (d) are often right against your face (Nikon, I'm looking at you and your ISO buttons), and (e) you need to keep them pushed while you turn a tiny little dial (which many of us are prone to overshoot with), (f) often with another finger of the same hand, very often while (g) keeping the shutter release button down half-pressed to keep focus locked. And it doesn't help that (h) you're squinting to look into an itty-bitty APS-C DSLR viewfinder.
Not to mention that these cameras have all been designed in an era where photographic exposure judgement is a lost art, and tend to actively punish skill at judging correct exposure by evaluating incident light (not reflected light!). The autoexposure cameras are built on the assumption that you're going to recompute exposure for every single shot. Skilled manual exposure shooters didn't do this; they set their exposure according to the light incident to the scene, and only changed the exposure level when the light changed, but they would make reciprocal changes to exposure and aperture that kept that exposure as needed. Trying to do this in M mode on one of those one-dial wonders is a big pain in the ass. P mode with program shift and exposure compensation comes really close, but it forces you into that "meter before every shot" mode that's just a waste of time when you already know what the correct exposure is.
And there's also the problem that in M mode, the viewfinder display of the difference between your exposure settings and the camera's metered value is normally tiny. Welcome to Squintsville once again.
Slashdot Mirror
I think you guys are having a very productive discussion right here.
I'll toss in something that I occasionally think about, that's related to what both of you are saying: the design of the operating systems in common use for personal computers. The kernels for Linux, OS X and Windows XP are all basically server technology that has been pressed to serve for desktop use. For example, all of them have been designed to maximize system throughput with techniques that increase end-user latency, like swap.
For example, the OS X Dock has a feature that magnifies the size of the icons as you mouse over them. However, when an OS X system faces memory pressure, the kernel will swap out pages that are in use by the Dock. When this happens, you get a pause of a few seconds between mousing over an icon and the computer magnifying it. The Dock is an element that is always present in the OS X user interface, but the kernel apparently doesn't know about that, and treats it as just another application that can be paged out to speed up something else. And more simply, switching to an application that's been unused for a while is often not just slow, but sluggish; it's not that the application takes a long time initially to perform the commands, it's that the application takes a long time to even respond to user input in the most basic ways.
An OS designed from scratch for personal computing would look quite different from what we have now. There would be a lot more emphasis on real-time response to user input. That's not what we've gotten. What we've gotten is, at best, hacks on top of timesharing server operating system kernels to make them less bad at interacting with the user.
Easy example: PostgreSQL doesn't have native materialized views, whereas SQL Server does have a materialized view implementation, which they call "indexed views." SQL Server indexed views are updated automatically on commits to the base tables of the view, so they're never out of date (unlike Oracle materialized views, for which the automatic updates on commit are an optional feature).
There are a bunch of articles online about how to simulate materialized views in PostgreSQL using tables and triggers, so you might argue that with a bunch of extra work, you could simulate most of what SQL Server is doing. However, there's more! SQL Server's query planner is capable of rewriting a query against the base tables to use an indexed view when appropriate. This means that you can, for example, speed up frequent queries that perform costly grouping and aggregation by creating an indexed view that precomputes the aggregate, without changing your query or application at all. This is impossible to reproduce in PostgreSQL; you'd have to change the application query to use the fake materialized view that you worked hard to create.
The list of things like this goes on and on. PostgreSQL is a decent database, especially given the fact that it's free as in speech; none of this is a discredit against it. But it's simply outclassed by SQL Server.
That is true in exactly the same way it is true that if it had rained during my walk yesterday, I would have gotten soaked.
Sure, let's grant that, for the sake of argument (though I'd say that most of the time it is true). Now, why do people keep developing new applications to use MySQL?
I can never get a good answer to this question. The answers I tend to get are of the form "because they don't want to spend the time to learn a new RDBMS." These people tend to spend a lot of time cleaning up after MySQL's flaws on applications that they inherited, too.
No, it's more like:
SQL Server is better than Postgres, period, and has tons of features that Postgres doesn't.
There are two versions of this argument:
I can buy the argument in case (1), but not in case (2). In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.
Give the higher ups a simple answer too: SQL Server 2000 Mainstream Support has ended.
None of those sound like a big problem for the authorities. Just make the GPS unit in the cars record your trajectory. Nearly all of the time it will be possible to tell whether you were on the fast road or on the slow one by the path you took before and after the apparent speeding.
SQL Server has always been a decent database. Going to PostgreSQL would probably be a downgrade. Though if I have to say one thing, it would be this: SQL Server 2005 is a lot better in my experience than 2000.
I think the ranchers oppose having their animals chipped because then it becomes too easy for the government to abuse its power and round their cattle up like cattle.
You're failing to understand precisely what "bankruptcy" means. Fundamentally, it means wiping out the shareholders of the corporations. Whether we bankrupt the banks is completely severable from whether we guarantee their customers' balances.
The better thing to do, IMO, would have been along similar lines to what FiloEleven says, but more moderate: nationalize the banks (which wipes out the shareholders) with a time cap on how long the government is allowed to own them, inject capital into them, guarantee whichever of the banks' obligations are deemed to be essential (first on the list: deposits), and then sell the banks. Result: depositors don't lose money, bank shareholders are wiped out as punishment for investing on a crappily run bank.
What we did, though, was to rescue everybody, including the shareholders. But the shareholders are precisely the folks that you should not be rescuing.
That's a myth, actually. But quite ironically, a lot of people in the USA seek health care treatment in Mexico.
A pyramid scheme doesn't lose any money on the aggregate, and it's still a scam.
Unlikely. Even if you got 3-10 years, the damages from the civil lawsuits against you would clean up. Your life might not be ruined, but for somebody like Madoff, he'd end up worse than he started.
Indeed. My family had an Atari 2600 when I was a kid, but we never had a NES. I hate those NES pads. And the world hates me, because DSLR cameras now have those.
The iPhone is winning on the basis of having a much superior interface. Open source development has always been notably bad at user interfaces, and more generally, at design; it is no accident that the most successful open source projects are all clones of some other software, or implementations of back-end protocols like HTTP. Very often superior clones, mind you, but it's still derivative.
Well, that says something neither good or bad about your taste, but stop imposing it on everybody else.
IANAL, but I think you're overestimating how much work one needs to do in order to get copyright on an edited version. I'm pretty sure if you renumber the pages and add an index to a public domain work, your edition qualifies for copyright protection. Same thing if you add some notes at the beginning, or add footnotes annotating the text, or hell, even if you create a new cover for the book. I would not be surprised if going through the old editions and fixing typos qualifies.
Note that the author in TFA was very careful to describe the product of a lot of these small presses as "facsimiles," and not "editions." That's a very crucial distinction there. A facsimile would be something like a photocopy or straight reprint of an old edition, and something that does not qualify for copyright protection.
That sounds like an oversight on Apple's part. In the desktop versions of OS X, the fields for wireless keys have a checkbox to unmask them, so we do know they've gotten it right in at least one product.
I don't think the proposal is to make it a difference. I think the proposal is to have password entry widgets have a little checkbox to control whether the text in them is masked, and have it default to unmasked. Whether you need masking or not is a case-by-case decision.
And, surprise, that's exactly what TFA recommends! Quote:
Deliberate untruths are lies, but not all lies are deliberate untruths. The most effective lies tend to be composed of nothing but true statements; the lie in that case consists of the deliberate omission of crucial information that the liar knows, in the expectation that the hearer will reach a desired false conclusion. The thing that makes those lies the "best" is that they're verifyable; if your victim takes care to check whether what you actually said is true, they will find that indeed it is, and that will reinforce the conclusion you want them to reach.
Nonsense. The rights of shareholders of a corporation to be informed about materially relevant information about the enterprise do not in general override the privacy rights of its CEO, only in very specific instances (e.g., the CEO is forced to disclose his transactions on company stock, and other dealings with the corporations such as pay and benefits). The possibility that the CEO of a corporation you're investing in is secretly very sick and will die soon is, well, just a risk that you have to take.
The greater depth of field of the GH1 is by no means a disadvantage. The idea that a camera like the GH1 is somehow crippled because it's DOF is wider is just an internets camera measurebator myth. The lenses needed for a sensor of the size of the GH1's are large enough to produce perfectly fine background blur, and you'll get more of your subject in focus thanks to the greater DOF. The larger sensor cameras shallower depth of field is in nearly every case a disadvantage, though one that they make up for thanks to having much larger sensors (and thus allowing you stop down the aperture and crank up the ISO).
These two posts at The Online Photographer make for instructive reading:
A lot of us can't ever press the correct button for all of this stuff without looking, given that they're all (a) tiny little buttons that (b) feel the same and (c) don't give you enough tactile feedback that you've pushed them, (d) are often right against your face (Nikon, I'm looking at you and your ISO buttons), and (e) you need to keep them pushed while you turn a tiny little dial (which many of us are prone to overshoot with), (f) often with another finger of the same hand, very often while (g) keeping the shutter release button down half-pressed to keep focus locked. And it doesn't help that (h) you're squinting to look into an itty-bitty APS-C DSLR viewfinder.
Not to mention that these cameras have all been designed in an era where photographic exposure judgement is a lost art, and tend to actively punish skill at judging correct exposure by evaluating incident light (not reflected light!). The autoexposure cameras are built on the assumption that you're going to recompute exposure for every single shot. Skilled manual exposure shooters didn't do this; they set their exposure according to the light incident to the scene, and only changed the exposure level when the light changed, but they would make reciprocal changes to exposure and aperture that kept that exposure as needed. Trying to do this in M mode on one of those one-dial wonders is a big pain in the ass. P mode with program shift and exposure compensation comes really close, but it forces you into that "meter before every shot" mode that's just a waste of time when you already know what the correct exposure is.
And there's also the problem that in M mode, the viewfinder display of the difference between your exposure settings and the camera's metered value is normally tiny. Welcome to Squintsville once again.