They released some code for public review. The codebase is full of holes and flaws, about like you'd expect any college student to put out.
If their product was a shopping cart, and the preview version of their software was massively secure but didn't let you list items, or let a user add items or checkout, I'd be critical too.
Their main feature was security - there are fsckloads of social network apps out there, so re-writing that part of the app wasn't the point of the project at all. Doing it securely was the point. Can it be fixed? Surely. But it still fails pretty miserably as a preview.
Wouldn't the police have to decide it was a criminal matter? If its stolen, then if he filed a police report, wouldn't that be good enough?
Good question. Of course, since he apparently hasn't filed a police report yet, despite the police statement strongly suggesting that if he did so, they'd be able to help him, we may never know.
This would be true if (and only if) the whole point of Diaspora wasn't to improve the security of your data. Seriously, that's the only significant quoted feature. And they didn't get that part close to right before launching? C'mon...
This would be true if (and only if) the whole point of Diaspora wasn't to improve the security of your data. Seriously, that's the only significant quoted feature. And they didn't get that part close to right before launching? C'mon...
I realize that grocery stores actually operate on pretty thin margins; but I have a very hard time believing that the fairly elaborate(and deeply buggy and annoying) "theft prevention" mechanisms in the self checkouts actually work well enough to justify their existence.
Even a minimum wage worker costs on the order of $32,000 per year, per shift, and can maybe process twice as many groceries as an automated lane. If an automated checkout lane costs $100,000, uses minimal electricity, and is available year-round, then you'd have four lanes ($400K) and one attendant per shift ($100K), or $500K for the first year and $100K for each year thereafter. For the same volume of customers, you'd need $200K per year, perpetually, and that's not including the initial cost of the manual checkout lanes.
You probably think that the only price you pay is the one you see at the cash register and would cheerfully live in a radioactive desert if it "saved" you money at the checkout counter.
You've turned yourself into an unpaid cashier. In other words, you are working for the store. For free. You trade quality of life for quality of service.
This math only applies as stated if the alternative is getting to walk right out the door without paying. For many people, the experience of operating a self-checkout once in a while is more pleasurable than the experience of waiting in line for an available register (fewer), then waiting again while someone else scans your groceries.
Depending on context, either approach may be better for the shopper - which is why many stores replace their 10-items-or-less lines with self-checkout, since the two often coincide.
The incumbent publishers want national legislatures to make this illegal for indies to do
Possibly, in part, because of comments by the grandparent post like:
I was unsuccessful in bribing the cable internet installer to "forget to block the TV signal"... I was faced with... paying for the TV services... I would simply rather do without.
Which I see that you blissfully ignored. When people are going out of their way to publicly point out that they were trying to steal the service, and would have done if it was technically possible for them, its not surprising that the publishers go out of their way to increase the difficulty of doing so. Just sayin'...
The option in question is only the first one on the first tab when you open the NoScript options screen.
And how, exactly, does that make the language I was complaining about easier to understand? It doesn't matter how accessible the checkbox is if nobody knows what happens when you check it.
And no useful bookmarking and link-sharing possible.
Anyway, there's a big mental difference between session-cookies (set to delete when you close your tab/window/os-login/whatever) and persisted cookies... few people argue against the utility of session cookies.
I love retards who think they know tech.. the option you refer to has existed in NoScript for a long time..
"Temporarily allow top-level sites by default"
I don't use NoScript personally, but I'm far from a tech-newbie. Having said that, nothing in the line you quoted would cause me to believe that this would "Allow javascript from the site you're on to run while blocking 3rd party scripts." Nothing at all. If anything, "Top-level" would seem to imply that JS from "domain.com" would be enabled, but "somewhere.domain.com" would not - which is just weird. Also, the conjunction of "temporarily" and "by default" is very strange and hard to read, even once you know what its supposed to mean. I'd guess that checking that would allow "top-level" JS to run by default, but the next time I started the browser it would go back to being disallowed - but I don't think that's what you're describing either.
"Allow javascript from the site you're on to run while blocking 3rd party scripts." - much harder to mis-understand.
Regarding the Transubstantiation... do Catholics believe is it literally the body and blood of Christ? They're supposed to, yes. Does that mean they think if put to scientific tests the results would yield anything other than bread and wine? Probably not. Part of faith is realizing that there are things one cannot understand and that they will remain a mystery, but that a person believes in them anyway.
Part of the confusion may be in that most people follow normal definitions for the words "literally," and "figuratively." If you say that something literally becomes something else, then its behavior should match the new item. If not, then not. Not a big deal.
And the day that an enlightened populace doesn't blame the vendor for the poor performance of their device when viewing sites crafted using a particular technology, they will.
Remember how everybody blamed MSFT when Windows 95 broke existing programs written by fans of Petzold's Undocumented Windows? Same problem, different words, except that Apple went the other way preemptively this time.
Or over there at Google, people are realizing that pushing a platform that's completely open and yet fully supported and still works perfectly when you swap out major components, like location services, is actually really hard.
There's a reason that Apple is a solutions provider rather than a hardware, OS, or software shop.
And you trust Server B to then discard the user's old stuff, when he's moving off Server B for a very good reason?
When the only main real-world reason being quoted to get people to move off FB is that you don't trust them? But you now trust Server B instead? And every single server in between them and the server of your friends in Tokyo and Milan?
The price of signing your driver is chump change to a multinational peripheral maker but substantial (200 USD per year) to an individual hobbyist or low-volume maker of custom assistive input devices for people with disabilities.
At least un the US (using that country because that's the pricing you quoted), $200 is chump change to anyone making any hardware of any sort whatsoever. Its also about 1/3 the cost of a low-end desktop machine. Is it free? No. Is it substantial, as you suggested? Also no. Even if you're a developer with no income whatsoever from your activities, chances are that one (and you only need one) of your users would be willing to sponsor your code signing in order to remove their personal annoyance about having to start in test mode to use your product.
And in exchange we get accountability for kernel mods. Seems like a reasonable trade-off to me.
The Apple version of Webkit (Safari) of course only runs on OSX, or OSX+iOS if you count Mobile Safari as the same browser.
Or, to put it another way, the standard Apple wrapper for Webkit is called Safari. The standard Windows wrappers for Webkit is called Chrome. The standard Linux wrapper for Webkit is also called Chrome.
When it comes to layout testing, the engine is vastly more important than the toolbar. Now, Chrome and Safari do use different Javascript interpreters, but I find that JS issues are almost always differences in the DOM rather than in implementing JS itself, so once again we're back to Webkit being the common denominator.
...will run only on x86 and x86-64.
Which, at the moment, represent the massively huge majority of systems that might want to support full-experience web-browsing (as opposed to just using HTTP occasionally). Until that changes, why would people increase their development and test cycles to support a miniscule market? Adding architectures to support does have a very real cost.
Sort of step backwards from the original Unix solution to portability: you write your stuff in C+POSIX, and then it runs everywhere we've ported a C compiler and a POSIX layer.
This would only be true if POSIX had been complete - for that matter, if C had been a complete specification. Big endian vs. little endian, for example? Portability always involves tradeoffs, either in development, testing, or performance. Always.
Having said that, non-display-interacting Java is amazingly close, to the point that we don't even blink twice when it comes to spinning up EARs on OSX vs. Linux, for example. But its not great in the GUI world.
Anyway, the other think to consider (especially for things like laser-based launches) is that the current "spit out a ton of speed really quickly and then coast your way to orbit" approach really sucks. Even a slow nice steady boost will get you to orbit without needing to hit escape velocity.
Without reading TFA I would confidently predict that the recordings will be made available in (at least) high quality Ogg Vorbis, lossless CD-quality Flac and some 24/32-bit/96/192Khz format for those who can appreciate such differences
With you on the Flac, but without reading TFA either (why spoil things), I will confidently predict that they won't release anything in Ogg Vorbis, because the very few people who care will be just as happy with Flac and can transcode themselves to their heart's content. I'd put money on MP3 or unprotected AAC being available, though.
Had they just requested sample prints, many (most?) shoe companies would probably have been happy to provide them with a full list - not because they had to, but because its a simple enough request to comply with. By doing the work themselves they ended up with less useful data that's, quite possibly, illegal to use.
I'm betting that screen resolution makes a pretty decent difference for some systems - FWIW, my numbers were at 1920x1080. All tests should be valid when compared against different browsers on the same machine, though.
Does this mean that I can use C# to generate a Silverlight app that will run on Windows, Windows Mobile, Linux, Android and iPhone?
Can I write in Java an app that will run on every desktop and mobile?
Well, considering that a good app experience on a desktop (with a mouse and keyboard) is by definition very different than a good app experience on a multi-touch device, probably not, no. You might be able to share some code internals, but you could do that anyway.
Slashdot Mirror
If their product was a shopping cart, and the preview version of their software was massively secure but didn't let you list items, or let a user add items or checkout, I'd be critical too.
Their main feature was security - there are fsckloads of social network apps out there, so re-writing that part of the app wasn't the point of the project at all. Doing it securely was the point. Can it be fixed? Surely. But it still fails pretty miserably as a preview.
Good question. Of course, since he apparently hasn't filed a police report yet, despite the police statement strongly suggesting that if he did so, they'd be able to help him, we may never know.
Sheesh.
This would be true if (and only if) the whole point of Diaspora wasn't to improve the security of your data. Seriously, that's the only significant quoted feature. And they didn't get that part close to right before launching? C'mon...
This would be true if (and only if) the whole point of Diaspora wasn't to improve the security of your data. Seriously, that's the only significant quoted feature. And they didn't get that part close to right before launching? C'mon...
Even a minimum wage worker costs on the order of $32,000 per year, per shift, and can maybe process twice as many groceries as an automated lane. If an automated checkout lane costs $100,000, uses minimal electricity, and is available year-round, then you'd have four lanes ($400K) and one attendant per shift ($100K), or $500K for the first year and $100K for each year thereafter. For the same volume of customers, you'd need $200K per year, perpetually, and that's not including the initial cost of the manual checkout lanes.
This math only applies as stated if the alternative is getting to walk right out the door without paying. For many people, the experience of operating a self-checkout once in a while is more pleasurable than the experience of waiting in line for an available register (fewer), then waiting again while someone else scans your groceries.
Depending on context, either approach may be better for the shopper - which is why many stores replace their 10-items-or-less lines with self-checkout, since the two often coincide.
Possibly, in part, because of comments by the grandparent post like:
Which I see that you blissfully ignored. When people are going out of their way to publicly point out that they were trying to steal the service, and would have done if it was technically possible for them, its not surprising that the publishers go out of their way to increase the difficulty of doing so. Just sayin'...
The option in question is only the first one on the first tab when you open the NoScript options screen.
And how, exactly, does that make the language I was complaining about easier to understand? It doesn't matter how accessible the checkbox is if nobody knows what happens when you check it.
And no useful bookmarking and link-sharing possible.
Anyway, there's a big mental difference between session-cookies (set to delete when you close your tab/window/os-login/whatever) and persisted cookies... few people argue against the utility of session cookies.
I don't use NoScript personally, but I'm far from a tech-newbie. Having said that, nothing in the line you quoted would cause me to believe that this would "Allow javascript from the site you're on to run while blocking 3rd party scripts." Nothing at all. If anything, "Top-level" would seem to imply that JS from "domain.com" would be enabled, but "somewhere.domain.com" would not - which is just weird. Also, the conjunction of "temporarily" and "by default" is very strange and hard to read, even once you know what its supposed to mean. I'd guess that checking that would allow "top-level" JS to run by default, but the next time I started the browser it would go back to being disallowed - but I don't think that's what you're describing either.
"Allow javascript from the site you're on to run while blocking 3rd party scripts." - much harder to mis-understand.
Part of the confusion may be in that most people follow normal definitions for the words "literally," and "figuratively." If you say that something literally becomes something else, then its behavior should match the new item. If not, then not. Not a big deal.
However, the article was specifically about the Pope's astronomer and, therefore, Catholic views, so it wasn't an unreasonable point to make.
And the day that an enlightened populace doesn't blame the vendor for the poor performance of their device when viewing sites crafted using a particular technology, they will.
Remember how everybody blamed MSFT when Windows 95 broke existing programs written by fans of Petzold's Undocumented Windows? Same problem, different words, except that Apple went the other way preemptively this time.
Or over there at Google, people are realizing that pushing a platform that's completely open and yet fully supported and still works perfectly when you swap out major components, like location services, is actually really hard.
There's a reason that Apple is a solutions provider rather than a hardware, OS, or software shop.
And you trust Server B to then discard the user's old stuff, when he's moving off Server B for a very good reason?
When the only main real-world reason being quoted to get people to move off FB is that you don't trust them? But you now trust Server B instead? And every single server in between them and the server of your friends in Tokyo and Milan?
Hmm. No, no worries there...
So.... you like it, but it doesn't have the people you want to connect to or the functionality you're looking for.
So.... why do you like it again? Honest question - I'm now quite curious. It doesn't seem to come close to meeting the needs you had...
At least un the US (using that country because that's the pricing you quoted), $200 is chump change to anyone making any hardware of any sort whatsoever. Its also about 1/3 the cost of a low-end desktop machine. Is it free? No. Is it substantial, as you suggested? Also no. Even if you're a developer with no income whatsoever from your activities, chances are that one (and you only need one) of your users would be willing to sponsor your code signing in order to remove their personal annoyance about having to start in test mode to use your product.
And in exchange we get accountability for kernel mods. Seems like a reasonable trade-off to me.
Or, to put it another way, the standard Apple wrapper for Webkit is called Safari. The standard Windows wrappers for Webkit is called Chrome. The standard Linux wrapper for Webkit is also called Chrome.
When it comes to layout testing, the engine is vastly more important than the toolbar. Now, Chrome and Safari do use different Javascript interpreters, but I find that JS issues are almost always differences in the DOM rather than in implementing JS itself, so once again we're back to Webkit being the common denominator.
Which, at the moment, represent the massively huge majority of systems that might want to support full-experience web-browsing (as opposed to just using HTTP occasionally). Until that changes, why would people increase their development and test cycles to support a miniscule market? Adding architectures to support does have a very real cost.
This would only be true if POSIX had been complete - for that matter, if C had been a complete specification. Big endian vs. little endian, for example? Portability always involves tradeoffs, either in development, testing, or performance. Always.
Having said that, non-display-interacting Java is amazingly close, to the point that we don't even blink twice when it comes to spinning up EARs on OSX vs. Linux, for example. But its not great in the GUI world.
Ah, Heinlein, may you never cease to spin.
Anyway, the other think to consider (especially for things like laser-based launches) is that the current "spit out a ton of speed really quickly and then coast your way to orbit" approach really sucks. Even a slow nice steady boost will get you to orbit without needing to hit escape velocity.
With you on the Flac, but without reading TFA either (why spoil things), I will confidently predict that they won't release anything in Ogg Vorbis, because the very few people who care will be just as happy with Flac and can transcode themselves to their heart's content. I'd put money on MP3 or unprotected AAC being available, though.
No, its small and awkwardly sized (hard to put it to the side of a shelf, etc). The new Apple TV is tiny. There's a difference.
Had they just requested sample prints, many (most?) shoe companies would probably have been happy to provide them with a full list - not because they had to, but because its a simple enough request to comply with. By doing the work themselves they ended up with less useful data that's, quite possibly, illegal to use.
Sigh...
I'm betting that screen resolution makes a pretty decent difference for some systems - FWIW, my numbers were at 1920x1080. All tests should be valid when compared against different browsers on the same machine, though.
Huh. I get Safari=7, Chrome=5, and Firefox3.6.9=3 running that test on a pretty recent MacBook Pro - current stable versions of each, I believe.
Does this mean that I can use C# to generate a Silverlight app that will run on Windows, Windows Mobile, Linux, Android and iPhone?
Can I write in Java an app that will run on every desktop and mobile?
Well, considering that a good app experience on a desktop (with a mouse and keyboard) is by definition very different than a good app experience on a multi-touch device, probably not, no. You might be able to share some code internals, but you could do that anyway.