It doesn't really matter though since the same concept applies to any files of any real size.
Minor nit -- no, it doesn't, it applies to any files of any real size which cannot be streamed. Counterexamples are videos, at the very least, and while I suspect OpenOffice loads the entire document, the design of an odp file is inherently seekable -- it's just a zipfile, so it can load each needed picture on demand. (I'm not sure if it does, but it's possible.)
However...
I have a problem with one of my coworkers who likes to run RDP sessions full screen. He often forgets he's directly on a server and then attempts to pull up a site like Hulu and subsequently finds flash not installed only to go ahead and install it.
So it basically boils down to what kind of applications you're running. In the Hulu example, the video stream itself would've been fine to send over the network -- if there was a video file in question, it could've been streamed -- it's just impractical to send the raw frames.
So, it seems to me that something like RDP usually provides a more reliable upper limit on the rate of data sent, while something like Samba can theoretically be much more efficient when applications are written with it in mind. Then again, the Hulu example proves that applications written without RDP in mind can also be a problem -- so it boils down to which protocol is more likely to have that kind of problem.
That is, do programs more frequently assume that the filesystem is local and fast, or that the screen is?
A few more nits:
Then there's this idea that screen scrolling would require an entire redownload of a frame which is simply untrue.
What I said is that once you've scrolled down a full page, that is a full frame.
Slashdot for instance is mostly white background which wouldn't have to be redownloaded.
At some point, yes it would. The sides would've been left alone, but where you actually have content, the fact that the background is white isn't really relevant -- it makes the image compress better, but a page full of text and white background is still going to end up as an image, which is larger than the original marked-up text.
You're still initializing your interpreter for EACH result set.
What do you mean by "initializing an interpreter"? It's already running, doesn't initialize even with each page in a well-designed system.
Plus, php deliberately doesn't let you execute multiple statements with one call
I'm not defending PHP specifically here, because that kind of stupidity doesn't seem like it's implied by an interpreter. Again, you are talking about a limitation in the current MySQL bindings, not in the language itself, and certainly not in the general design of an interpreted language.
Of course a c program has to do sanity checks on data as well, but it's a lot easier.
I dispute that. For example:
For example, if you KNOW that you'll never get a response from the end user that's longer than 2k, as soon as you exceed that limit, stop reading from the socket,
And if you forget to do that, but you've only allocated the 2k, that's a buffer overflow -- a kind of security vulnerability which you cannot create in PHP. I'd rather have a DoS than a real security flaw any day.
Contrast that against the need to download that 1gig powerpoint presentation over the Internet over ATT 3G spotty speed
Well, first of all, this only makes sense when we're actually talking about that 3G connection...
But also, consider that the PowerPoint document can be cached locally, and even worked on offline. Also, any intelligent network filesystem should allow you to transfer pieces of a file, so if you're writing software that could conceivably have to deal with files that huge (seriously, I don't think I've ever seen a 1 gig PowerPoint presentation), you can write it to only load what's needed for the moment.
So, sending pictures makes sense in that it's a constant, predictable rate, even though it's going to be more on average:
Scrolling only requires downloading enough of the screen to cover the new info to be displayed, usually the process of scrolling gives the machine enough time to download it.
Yet it's still additional information -- if you scroll down an entire screenfull, you've at least doubled the amount of information needed -- and the original picture of a webpage is very likely larger than the entire contents of that page as HTML.
Well, the obvious solution would be to actually talk about this with the developer, "buddy-buddy" or not.
I'm a bit amazed no one mentioned this before. From TFA:
I said, “You know, I think I got this. You don’t have to stay.”
Sounds like he expressed this to his manager, though not as clearly as he could've been -- "I think it would be easier to do this alone." But what makes this especially annoying is the manager's response:
“Sure I do!” he said with sincere enthusiasm.
Basically discarding what the developer wants or feels might be most useful.
So when it's his turn, he makes no mention of actually discussing it with the developer in question. Instead, he asks the entire fucking Internet for advice, instead of the one person he should have asked.
The same goes for a parent. Trying to decide whether to get chocolate or vanilla ice cream for your kid's birthday? Ask them!
We also export pictures of our data to users, not the data itself, which is quite a bonus.
How so?
Last I tried this, I found that for the vast majority of things you'd like to do, sending a picture of the data (even a compressed picture) is likely to be much larger than the data itself. The Slashdot homepage is 108 kilobytes. A PNG image of the Slashdot homepage was 220 kilobytes, and even when compressed with 'pngcrush -brute' (which takes something like 30 seconds on my machine) only gets it down to 173 kilobytes.
So even if you have unlimited time and power to compress the image, if you're going to deliver it perfectly, it's going to be 65 kilobytes more -- and that's just for what's visible within the frame. If I scroll, even if you use some sort of brilliant delta-compression, you're adding to the count -- again, compared with 108 kilobytes.
It's hard to imagine what kind of file is going to be larger than a picture of that file.
Maybe I'm missing the point? Maybe it's some sort of poor-man's DRM -- you don't want someone to be able to just walk off with the original data, but it's not as bad if they walk off with a screenshot?
if people can't be bothered to look up and consider important things like food safety on their own, is trusting them with electing politicians anymore solving the problem (and not creating new ones)?
The suggestion is that people should consider electing politicians to be their job, and an important one at that. Ensuring food safety, electrical appliance safety, safe cars, safe chemicals, safe software, safe building materials, and so on, should not be the consumer's job, at least, not directly.
Or, how about, if you're ever concerned about the cleanliness of food, you shouldn't eat there?
Say I'm from out of town. Hell yes I'm concerned, now where do I eat? I know nothing of the locals, and nothing of the local restaurants. My best bet is to go on my own intuition of what looks clean, and on the assumption that these places are regularly inspected.
Honestly, though, I'm not sure people, even you, truly care about this. I'm sure you've eaten food your friends have cooked, possibly in questionable conditions in their kitchens, without your own concern.
Given that they are my friends, I trust them to not deliberately put themselves or me in jeopardy. Given that they are cooking for me, chances are they are at least somewhat conscious of the quality of their food, in more ways than just cleanliness.
Contrast that to a restaurant -- if they make really cheap food that sometimes makes people sick, but no one makes the connection, they stay in business. For that matter, maybe the food is all contaminated, but the locals have developed an immunity -- so it stays in business, but people from out of town get sick.
This is why we have specialization. It's not "meh, it's too much work", it's the fact that even if I was motivated, it's impossible for me to become an expert in everything, even to the point where I'd know which of the competing certifications on the wall I should pay attention to. The argument is often made on Slashdot that the average customer shouldn't have to care what web browser they use -- if true, why should I have to pay attention to which brand of car I drive, just to make sure it won't explode?
I mean, following this rabbit hole:
People shouldn't expect or assume anything... You should always be reading reviews on a product, so on, so forth.
Now, how would I know which reviews are legitimate? In the case of buyer reviews, how do I know which ones aren't astroturfing by the company?
IF the browser provides the code with full access to all of the device's features, including graphics acceleration,
WebGL.
audio mixing,
You got me here.
proper responsive input, and so on.
What's wrong with input as it stands?
what's the real-world likelihood of there being a standard method for accessing all these device-specific functions?
What about them is device-specific?
It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts...
Is it still hit-and-miss if you take IE out of the equation?
is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps?
Not that I want to see this any more than you do, but the answer is, unquestionably, yes. Firefox is open source, and is already more standards-compliant than IE6 ever was.
The logical reasons are that: a) you have to be online to use it;
"Work offline" + offline storage.
b) you're running an app within an app.
So's anything that runs on an OS. So's anything that uses a runtime -- any Java, Ruby, Python, Perl, most Lisp apps, even C, if it happens to be compiled for LLVM. As a logical argument, it falls flat on its face until you have something specific.
So how do I exit the browser app, then?
Same way you exit any app, I suspect...
This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu?
I've never really felt the need to have a menu in a web app. But you do have a point here, and I'd think this is something that could be negotiated in two ways:
First, it's entirely up to the browser whether the web app can override the browser's keyboard shortcuts.
Second, both the browser and the web app could theoretically allow the user to customize keybindings. It's nowhere near as convenient as it could be, but it works.
It would be better if the app could detect the scheme in place by the browser. One hack would be to look at the user-agent string...
But it's worth mentioning that every existing app has the exact same problem -- some keystrokes (or buttons) are used by the OS. I wouldn't want to use alt+f2 in a Linux app, and I _couldn't_ use ctrl+alt+del in a Windows app.
Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.
Well, except that such a launcher already exists in Chrome (both the browser and the OS) -- but you're right, having a launcher is not an advantage of web apps.
But then it comes to my practical reason for disliking them: nearly all of them suck compared to native alternatives.
Assuming native alternatives exist, maybe... But I often, repeatedly, challenge people for specific problems they have with web apps, and I don't often get a response of something a native app can do that a web app can't, other than something which is, currently, categorically out of their reach due to API limitations. (For example, high-end CAD software can't be a web app until we get some decent 3D graphics.)
Their only advantage is that you don't need to install them, so you can access them from any computer.
That's far from the only advantage. Theoretically, you could also make that an advantage of native apps, and the only reason it would apply more to web apps is that everything already has a browser.
Even if you're not an Apple fan, you have to give them credit for recasting the cellphone world and removing the chokehold the carriers had on costs, phones, customer service, etc, etc.
Sorry, what? No I don't.
What, exactly, has Apple done to help that situation?
The frustrating fact is that if you actually avoid every market that's either regulated or in massive collusion, you'll find yourself giving up many modern conveniences. Not just cell phones, but the telephone in general -- just why do you think land lines are reasonable now?
If you believe what the salesman tells you then you are already a lost cause. His job isn't to look out for your best interest. His job is to sell.
Shortsighted at best. His job may well be to sell to you, personally, and he may get a commission from you. But ripping you off with a bullshit story is detrimental to the company as a whole, at least in theory.
But the world doesn't run on wishes. You can't escape the necessity for people to be responsible and informed, first and foremost, and when they are that makes the need for regulation unnecessary.
That just about made me do a double-take.
The world doesn't run on wishes. You can't escape the reality that people won't be responsible and informed. Informed is important here, too, and is part of the job of regulation -- for example, we have laws about food safety, so I can walk into any restaurant with some confidence that the food there is safe to eat. You could have a totally free market, in which independent organizations certify particular restaurants as "safe", but then the customers would have to constantly be checking those certifications.
Arthur Grumbine pointed out you can remove bloat from Windows with tools such as nLite,
While replying to a post claiming you can remove bloat from Linux.
Which replied to a post claiming the Linux kernel is bloated.
So if you follow the chain of implication back up, the "you can remove bloat from Linux" post would've meant "you can remove bloat from the Linux kernel", which is true -- make menuconfig.
Someone then replied to that with nLite, implying nLite can do the same for Windows that 'make menuconfig' does for Linux.
I think it's entirely accurate to then ask whether nLite actually does that for the kernel, to bring us back on topic.
The implication being that the NT kernel is bloated.
I intended no such implication. In fact, if you are right, so am I -- if the NT kernel is completely not bloated at all, and there's no room to reasonably streamline it, then nLite certainly doesn't remove any bloat from the kernel, since there was none there to remove.
I'm sure it looks like I'm trying to weasel-word my way out of this, but no, I don't actually know enough about the NT kernel to say much either way -- I'm merely pointing out that as far as I know, nLite doesn't touch it.
I'd wager he's misinterpreting what Linus Torvalds meant. I'm not sure Linus meant the kernel is bloated in the binary/memory footprint sense, but more that the source code has grown very large,
I suspect it was vaguer than that. It is true in both senses, though. It's getting more and more difficult to fit any sort of kernel on a floppy, whereas it used to be reasonable to fit an entire kernel for your system on a floppy, and theoretically possible to fit an entire Linux system on a floppy. And the kernel source itself is getting larger and larger, because as long as it's a monolithic kernel, it is easier to have something maintained with the kernel than outside of it.
What I suspect happened is that until my comment, people were interpreting the "Linux is bloated" to mean the entire OS is bloated. This is also true, and it's also true that you can strip away Linux bloat by choosing a different distro, and the result can be much smaller than the result of nLite on a recent Windows -- all of these were valid points. But I wanted to bring it back to the fact that the original "Linux is bloated" comment wasn't talking about the distro, it was talking about the kernel, and the poster even said so.
For example, if I want to restore that backup into an existing system, the merge of those SQL databases is nontrivial at best, disaster-prone at worst, and insane in general.
Would you expect to be able to do the same with cookies?
The simple solution is, choose one database or the other, don't try to merge them. It's got one SQLite database per domain, and chances are, you really don't want to try merging them within a domain.
About freaking time.
Sure, but again, it's something various UI libraries have had for awhile.
Upon further looking, I see Safari 4 does. I retract that statement.
Not all of the demos seem to run, but I have gotten a few to work on Chrome 4 Beta.
For example, if I tried to build a computer whose whole programming interface was a browser, even trivial tasks like renaming files or copying photos off a flash drive would not be practical without significantly changing the basic model for interaction between the browser and the hardware.
Check out the demo of Chrome OS.
And no, it doesn't seem like there's much difference at all -- you'd just need to expose an API, and only to trusted apps. Take Chrome Extensions -- when writing an extension, I can choose exactly what I need to access, and users will know that when they install it. I have one installed right now that, in theory, has access to "all my private data on youtube.com" -- while I still wish it could do what it does without that, it's still much easier to swallow than an extension having access to everything.
Chrome extensions are pretty much chunks of Javascript and HTML. In extreme situations, you can include a plugin inside your extension, but that's a last resort.
For example, if you need a 100 pixel area and a second area beside it that tries to be the same as the remaining size in the enclosing container, different browsers seem to interpret that "100%" subtly differently (with IE typically being the worst offender).
I guess I'll have to test this out, but I'm curious. How are they different, especially in non-IE browsers?
Worst case, it is possible to have CSS effectively style things as though they were table cells.
The classic one that's a pain in the ass to get right is trying to specify a border image.
Is this something non-web GUIs have right?
I can't remember what problems I've had with the button tag, only that I've had problems with it.
I know the biggest objection I usually run into is people who want to re-style everything. There seems to be a mantra among designers that "default is ugly" -- specifically when referring to form controls, especially buttons, checkboxes, etc.
What's often forgotten is that there's nothing in the spec which says they have to be ugly. Indeed, modern OSes allow these things to be styled quite a lot, and the defaults don't look bad on OS X -- or Linux, IMHO.
But I'll give you the benefit of the doubt here -- it might have been something else.
The whole thing also has an annoying flaw in that it is based on an arbitrary device-independent pixel size, but most browsers don't support fractional pixels, making it really rather problematic to do precise layout
I suppose I consider the lack of "precise layout" in this sense to be a feature. That is, while it would be nice if we could get everything lined up to the sub-pixel, as a user, I prefer sites with simpler designs -- things which are flexible, where layouts are measured in ems and flow with the font size...
Regarding the columns stuff, I haven't looked at the CSS3 column bits. That either didn't exist or wasn't supported in Safari the last time I tried to do a columnar layout.
I do see some obvious problems with it, but it does look like it works for most of what people were wanting. It does work on this Chrome beta.
The former category is a lost cause and will just use IE anyway because that's what they know.
Want to bet?
Ever since XP, there has been a prominent link on the Start Menu to "The Internet", which opens the current default browser. It's far bigger and more obvious than "Internet Explorer".
No, these users aren't going to have a clue what a browser is, the words "Internet Explorer" will likely mean nothing to them. They might just pick IE because it sounds right -- but they might as easily pick Google Chrome because they know they use Google.
However, I suspect it's far more likely that they'll try to figure out how to get rid of that annoying popup, rather than bothering to actually read it. So, sadly, they might end up with IE just by figuring out that they can close the ballot screen by clicking the X in the upper right.
Rather than making sure that all the components of Windows are installed, that all the crapware is installed, dealing with disks, etc.
Do you know how a disk image works? It's really very little more work to image a hard disk than to just put a brand-new, blank one in there.
You are kidding right? IBM (who had a near total monopoly on computer systems at the time) needed an OS, so MS basically bought DOS from a couple of guys who made it and licensed it to IBM.
True.
DOS was -terrible- but due to IBM's monopoly its what people used,
True -- and that should be a period, not a comma.
when people realized they could build an IBM-compatible machine the clones started coming out and they wanted software compatibility so they licensed DOS too.
See, here's where you're missing a key piece of information:
Microsoft managed to sell DOS to IBM... but not as an exclusive arrangement. Because of this, Microsoft could then turn around and sell DOS (and later Windows) to any IBM clone who wanted it.
Without this, it wouldn't have mattered -- those IBM clones would've been exactly as successful as Pystar.
Microsoft was in no way a major player, the events that happened would have happened without Microsoft's assistance. It was inevitable that the IBM PC would be reverse engineered and cheaper clones could be produced.
Impossible to say -- but it does seem likely that IBM would have released their own OS, and one which was licensed only for use on IBM machines. The evidence is obvious -- IBM did have a PC OS at one point (OS2), and if you look at how their mainframe OSes are licensed, it wouldn't be surprising at all for it to be licensed for IBM PCs only.
At that point, it could very well be that Apple would've won. The biggest reason they didn't is that they discouraged clones, while IBM allowed them -- thus, PC hardware got cheaper and cheaper, culminating in Apple's move to Intel because the Power architecture simply couldn't compete. Power may have been superior technology, but Intel was cheaper, mass-produced, and evolving faster.
You'll notice I snipped this part. That's because it deserves special ridicule:
(thankfully there was no DMCA or other restrictive laws back then)
"Restrictive" like, I don't know, copyright itself? Software became copyrightable in 1980. The initial release of MS-DOS was in 1981. And copyright is all you need to sell a "license to use", rather than a mere copy of the software.
Either that, or they think the games aren't important...
There's something specific. I can work with that.
What about a web browser isn't suitable for games?
Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.
Depends what X is, but it doesn't sound particularly hard.
for other phones which use physical buttons, not having access to them makes for a significant decrease in usability.
So expose them as keystrokes, which web apps do have access to.
Even on the iPhone: can a web app make proper use of multi-touch?
I'm not sure, though apparently Firefox Mobile exposes even the accelerometer to the web app.
A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work.
That's only if you assert Javascript isn't appropriate for this. I disagree. As you say:
The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.
Except that you still have the advantage of write-once, install anywhere, automatic sandboxing, updates, and everything else.
If you think the only advantage of a web app is being able to write it in your own language on the server-side, you have wildly missed the point.
I doubt very much there's any intelligent pro-Sony, pro-OSS person.
Yes, the PS2 had Linux. It cost $200, and included a hard drive. There was no other legal way to do it. But hey, at least it had full access to the hardware.
The PS3 also has Linux, but this time, they've crippled it by running it in a hypervisor -- that is, a virtual machine.
Linux people also tend to be anti-DRM. Sony has, among other things, created DVDs which couldn't be played in most computers (or many Sony DVD players) by deliberately breaking the spec in a way they assumed would apply only to PCs, and released music CDs with a Windows rootkit installed on autoplay which makes your computer measurably less secure and slower, all in order to prevent you from "unauthorized" use, which apparently includes ripping.
I mean, I'm sure there are some people who are simultaneously Linux fanboys and Sony fanboys, but it's a position that doesn't make much sense.
Slashdot Mirror
It doesn't really matter though since the same concept applies to any files of any real size.
Minor nit -- no, it doesn't, it applies to any files of any real size which cannot be streamed. Counterexamples are videos, at the very least, and while I suspect OpenOffice loads the entire document, the design of an odp file is inherently seekable -- it's just a zipfile, so it can load each needed picture on demand. (I'm not sure if it does, but it's possible.)
However...
I have a problem with one of my coworkers who likes to run RDP sessions full screen. He often forgets he's directly on a server and then attempts to pull up a site like Hulu and subsequently finds flash not installed only to go ahead and install it.
So it basically boils down to what kind of applications you're running. In the Hulu example, the video stream itself would've been fine to send over the network -- if there was a video file in question, it could've been streamed -- it's just impractical to send the raw frames.
So, it seems to me that something like RDP usually provides a more reliable upper limit on the rate of data sent, while something like Samba can theoretically be much more efficient when applications are written with it in mind. Then again, the Hulu example proves that applications written without RDP in mind can also be a problem -- so it boils down to which protocol is more likely to have that kind of problem.
That is, do programs more frequently assume that the filesystem is local and fast, or that the screen is?
A few more nits:
Then there's this idea that screen scrolling would require an entire redownload of a frame which is simply untrue.
What I said is that once you've scrolled down a full page, that is a full frame.
Slashdot for instance is mostly white background which wouldn't have to be redownloaded.
At some point, yes it would. The sides would've been left alone, but where you actually have content, the fact that the background is white isn't really relevant -- it makes the image compress better, but a page full of text and white background is still going to end up as an image, which is larger than the original marked-up text.
You're still initializing your interpreter for EACH result set.
What do you mean by "initializing an interpreter"? It's already running, doesn't initialize even with each page in a well-designed system.
Plus, php deliberately doesn't let you execute multiple statements with one call
I'm not defending PHP specifically here, because that kind of stupidity doesn't seem like it's implied by an interpreter. Again, you are talking about a limitation in the current MySQL bindings, not in the language itself, and certainly not in the general design of an interpreted language.
Of course a c program has to do sanity checks on data as well, but it's a lot easier.
I dispute that. For example:
For example, if you KNOW that you'll never get a response from the end user that's longer than 2k, as soon as you exceed that limit, stop reading from the socket,
And if you forget to do that, but you've only allocated the 2k, that's a buffer overflow -- a kind of security vulnerability which you cannot create in PHP. I'd rather have a DoS than a real security flaw any day.
That's actually a good point... sort of.
Contrast that against the need to download that 1gig powerpoint presentation over the Internet over ATT 3G spotty speed
Well, first of all, this only makes sense when we're actually talking about that 3G connection...
But also, consider that the PowerPoint document can be cached locally, and even worked on offline. Also, any intelligent network filesystem should allow you to transfer pieces of a file, so if you're writing software that could conceivably have to deal with files that huge (seriously, I don't think I've ever seen a 1 gig PowerPoint presentation), you can write it to only load what's needed for the moment.
So, sending pictures makes sense in that it's a constant, predictable rate, even though it's going to be more on average:
Scrolling only requires downloading enough of the screen to cover the new info to be displayed, usually the process of scrolling gives the machine enough time to download it.
Yet it's still additional information -- if you scroll down an entire screenfull, you've at least doubled the amount of information needed -- and the original picture of a webpage is very likely larger than the entire contents of that page as HTML.
I believe it's more sending a copy of the data, and only letting users modify that copy as opposed to the stored data.
Erm, what?
First: How can this not be done with a Samba mount? And second: How can this be done at all with an RDP connection?
Well, the obvious solution would be to actually talk about this with the developer, "buddy-buddy" or not.
I'm a bit amazed no one mentioned this before. From TFA:
I said, “You know, I think I got this. You don’t have to stay.”
Sounds like he expressed this to his manager, though not as clearly as he could've been -- "I think it would be easier to do this alone." But what makes this especially annoying is the manager's response:
“Sure I do!” he said with sincere enthusiasm.
Basically discarding what the developer wants or feels might be most useful.
So when it's his turn, he makes no mention of actually discussing it with the developer in question. Instead, he asks the entire fucking Internet for advice, instead of the one person he should have asked.
The same goes for a parent. Trying to decide whether to get chocolate or vanilla ice cream for your kid's birthday? Ask them!
Why is it that a decent PHP (or Python, or Ruby) MySQL binding couldn't do the exact same thing?
We also export pictures of our data to users, not the data itself, which is quite a bonus.
How so?
Last I tried this, I found that for the vast majority of things you'd like to do, sending a picture of the data (even a compressed picture) is likely to be much larger than the data itself. The Slashdot homepage is 108 kilobytes. A PNG image of the Slashdot homepage was 220 kilobytes, and even when compressed with 'pngcrush -brute' (which takes something like 30 seconds on my machine) only gets it down to 173 kilobytes.
So even if you have unlimited time and power to compress the image, if you're going to deliver it perfectly, it's going to be 65 kilobytes more -- and that's just for what's visible within the frame. If I scroll, even if you use some sort of brilliant delta-compression, you're adding to the count -- again, compared with 108 kilobytes.
It's hard to imagine what kind of file is going to be larger than a picture of that file.
Maybe I'm missing the point? Maybe it's some sort of poor-man's DRM -- you don't want someone to be able to just walk off with the original data, but it's not as bad if they walk off with a screenshot?
Except for, ironically, Windows Mobile.
if people can't be bothered to look up and consider important things like food safety on their own, is trusting them with electing politicians anymore solving the problem (and not creating new ones)?
The suggestion is that people should consider electing politicians to be their job, and an important one at that. Ensuring food safety, electrical appliance safety, safe cars, safe chemicals, safe software, safe building materials, and so on, should not be the consumer's job, at least, not directly.
You can't be an expert in everything.
Or, how about, if you're ever concerned about the cleanliness of food, you shouldn't eat there?
Say I'm from out of town. Hell yes I'm concerned, now where do I eat? I know nothing of the locals, and nothing of the local restaurants. My best bet is to go on my own intuition of what looks clean, and on the assumption that these places are regularly inspected.
Honestly, though, I'm not sure people, even you, truly care about this. I'm sure you've eaten food your friends have cooked, possibly in questionable conditions in their kitchens, without your own concern.
Given that they are my friends, I trust them to not deliberately put themselves or me in jeopardy. Given that they are cooking for me, chances are they are at least somewhat conscious of the quality of their food, in more ways than just cleanliness.
Contrast that to a restaurant -- if they make really cheap food that sometimes makes people sick, but no one makes the connection, they stay in business. For that matter, maybe the food is all contaminated, but the locals have developed an immunity -- so it stays in business, but people from out of town get sick.
This is why we have specialization. It's not "meh, it's too much work", it's the fact that even if I was motivated, it's impossible for me to become an expert in everything, even to the point where I'd know which of the competing certifications on the wall I should pay attention to. The argument is often made on Slashdot that the average customer shouldn't have to care what web browser they use -- if true, why should I have to pay attention to which brand of car I drive, just to make sure it won't explode?
I mean, following this rabbit hole:
People shouldn't expect or assume anything... You should always be reading reviews on a product, so on, so forth.
Now, how would I know which reviews are legitimate? In the case of buyer reviews, how do I know which ones aren't astroturfing by the company?
IF the browser provides the code with full access to all of the device's features, including graphics acceleration,
WebGL.
audio mixing,
You got me here.
proper responsive input, and so on.
What's wrong with input as it stands?
what's the real-world likelihood of there being a standard method for accessing all these device-specific functions?
What about them is device-specific?
It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts...
Is it still hit-and-miss if you take IE out of the equation?
is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps?
Not that I want to see this any more than you do, but the answer is, unquestionably, yes. Firefox is open source, and is already more standards-compliant than IE6 ever was.
The logical reasons are that: a) you have to be online to use it;
"Work offline" + offline storage.
b) you're running an app within an app.
So's anything that runs on an OS. So's anything that uses a runtime -- any Java, Ruby, Python, Perl, most Lisp apps, even C, if it happens to be compiled for LLVM. As a logical argument, it falls flat on its face until you have something specific.
So how do I exit the browser app, then?
Same way you exit any app, I suspect...
This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu?
I've never really felt the need to have a menu in a web app. But you do have a point here, and I'd think this is something that could be negotiated in two ways:
First, it's entirely up to the browser whether the web app can override the browser's keyboard shortcuts.
Second, both the browser and the web app could theoretically allow the user to customize keybindings. It's nowhere near as convenient as it could be, but it works.
It would be better if the app could detect the scheme in place by the browser. One hack would be to look at the user-agent string...
But it's worth mentioning that every existing app has the exact same problem -- some keystrokes (or buttons) are used by the OS. I wouldn't want to use alt+f2 in a Linux app, and I _couldn't_ use ctrl+alt+del in a Windows app.
Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.
Well, except that such a launcher already exists in Chrome (both the browser and the OS) -- but you're right, having a launcher is not an advantage of web apps.
But then it comes to my practical reason for disliking them: nearly all of them suck compared to native alternatives.
Assuming native alternatives exist, maybe... But I often, repeatedly, challenge people for specific problems they have with web apps, and I don't often get a response of something a native app can do that a web app can't, other than something which is, currently, categorically out of their reach due to API limitations. (For example, high-end CAD software can't be a web app until we get some decent 3D graphics.)
Their only advantage is that you don't need to install them, so you can access them from any computer.
That's far from the only advantage. Theoretically, you could also make that an advantage of native apps, and the only reason it would apply more to web apps is that everything already has a browser.
But some
Even if you're not an Apple fan, you have to give them credit for recasting the cellphone world and removing the chokehold the carriers had on costs, phones, customer service, etc, etc.
Sorry, what? No I don't.
What, exactly, has Apple done to help that situation?
The frustrating fact is that if you actually avoid every market that's either regulated or in massive collusion, you'll find yourself giving up many modern conveniences. Not just cell phones, but the telephone in general -- just why do you think land lines are reasonable now?
If you believe what the salesman tells you then you are already a lost cause. His job isn't to look out for your best interest. His job is to sell.
Shortsighted at best. His job may well be to sell to you, personally, and he may get a commission from you. But ripping you off with a bullshit story is detrimental to the company as a whole, at least in theory.
But the world doesn't run on wishes. You can't escape the necessity for people to be responsible and informed, first and foremost, and when they are that makes the need for regulation unnecessary.
That just about made me do a double-take.
The world doesn't run on wishes. You can't escape the reality that people won't be responsible and informed. Informed is important here, too, and is part of the job of regulation -- for example, we have laws about food safety, so I can walk into any restaurant with some confidence that the food there is safe to eat. You could have a totally free market, in which independent organizations certify particular restaurants as "safe", but then the customers would have to constantly be checking those certifications.
There are two tiny pictures there, but no videos, and no links other than to another press release which also doesn't have videos.
Am I just not looking hard enough?
Arthur Grumbine pointed out you can remove bloat from Windows with tools such as nLite,
While replying to a post claiming you can remove bloat from Linux.
Which replied to a post claiming the Linux kernel is bloated.
So if you follow the chain of implication back up, the "you can remove bloat from Linux" post would've meant "you can remove bloat from the Linux kernel", which is true -- make menuconfig.
Someone then replied to that with nLite, implying nLite can do the same for Windows that 'make menuconfig' does for Linux.
I think it's entirely accurate to then ask whether nLite actually does that for the kernel, to bring us back on topic.
The implication being that the NT kernel is bloated.
I intended no such implication. In fact, if you are right, so am I -- if the NT kernel is completely not bloated at all, and there's no room to reasonably streamline it, then nLite certainly doesn't remove any bloat from the kernel, since there was none there to remove.
I'm sure it looks like I'm trying to weasel-word my way out of this, but no, I don't actually know enough about the NT kernel to say much either way -- I'm merely pointing out that as far as I know, nLite doesn't touch it.
I'd wager he's misinterpreting what Linus Torvalds meant. I'm not sure Linus meant the kernel is bloated in the binary/memory footprint sense, but more that the source code has grown very large,
I suspect it was vaguer than that. It is true in both senses, though. It's getting more and more difficult to fit any sort of kernel on a floppy, whereas it used to be reasonable to fit an entire kernel for your system on a floppy, and theoretically possible to fit an entire Linux system on a floppy. And the kernel source itself is getting larger and larger, because as long as it's a monolithic kernel, it is easier to have something maintained with the kernel than outside of it.
What I suspect happened is that until my comment, people were interpreting the "Linux is bloated" to mean the entire OS is bloated. This is also true, and it's also true that you can strip away Linux bloat by choosing a different distro, and the result can be much smaller than the result of nLite on a recent Windows -- all of these were valid points. But I wanted to bring it back to the fact that the original "Linux is bloated" comment wasn't talking about the distro, it was talking about the kernel, and the poster even said so.
What evidence do you have of the NT kernel being bloated?
That's not really relevant at all. Go all the way up to the LOLLinux troll -- it specifically mentions the Linux kernel becoming bloated.
For example, if I want to restore that backup into an existing system, the merge of those SQL databases is nontrivial at best, disaster-prone at worst, and insane in general.
Would you expect to be able to do the same with cookies?
The simple solution is, choose one database or the other, don't try to merge them. It's got one SQLite database per domain, and chances are, you really don't want to try merging them within a domain.
About freaking time.
Sure, but again, it's something various UI libraries have had for awhile.
Upon further looking, I see Safari 4 does. I retract that statement.
Not all of the demos seem to run, but I have gotten a few to work on Chrome 4 Beta.
For example, if I tried to build a computer whose whole programming interface was a browser, even trivial tasks like renaming files or copying photos off a flash drive would not be practical without significantly changing the basic model for interaction between the browser and the hardware.
Check out the demo of Chrome OS.
And no, it doesn't seem like there's much difference at all -- you'd just need to expose an API, and only to trusted apps. Take Chrome Extensions -- when writing an extension, I can choose exactly what I need to access, and users will know that when they install it. I have one installed right now that, in theory, has access to "all my private data on youtube.com" -- while I still wish it could do what it does without that, it's still much easier to swallow than an extension having access to everything.
Chrome extensions are pretty much chunks of Javascript and HTML. In extreme situations, you can include a plugin inside your extension, but that's a last resort.
For example, if you need a 100 pixel area and a second area beside it that tries to be the same as the remaining size in the enclosing container, different browsers seem to interpret that "100%" subtly differently (with IE typically being the worst offender).
I guess I'll have to test this out, but I'm curious. How are they different, especially in non-IE browsers?
Worst case, it is possible to have CSS effectively style things as though they were table cells.
The classic one that's a pain in the ass to get right is trying to specify a border image.
Is this something non-web GUIs have right?
I can't remember what problems I've had with the button tag, only that I've had problems with it.
I know the biggest objection I usually run into is people who want to re-style everything. There seems to be a mantra among designers that "default is ugly" -- specifically when referring to form controls, especially buttons, checkboxes, etc.
What's often forgotten is that there's nothing in the spec which says they have to be ugly. Indeed, modern OSes allow these things to be styled quite a lot, and the defaults don't look bad on OS X -- or Linux, IMHO.
But I'll give you the benefit of the doubt here -- it might have been something else.
The whole thing also has an annoying flaw in that it is based on an arbitrary device-independent pixel size, but most browsers don't support fractional pixels, making it really rather problematic to do precise layout
I suppose I consider the lack of "precise layout" in this sense to be a feature. That is, while it would be nice if we could get everything lined up to the sub-pixel, as a user, I prefer sites with simpler designs -- things which are flexible, where layouts are measured in ems and flow with the font size...
Regarding the columns stuff, I haven't looked at the CSS3 column bits. That either didn't exist or wasn't supported in Safari the last time I tried to do a columnar layout.
I do see some obvious problems with it, but it does look like it works for most of what people were wanting. It does work on this Chrome beta.
The former category is a lost cause and will just use IE anyway because that's what they know.
Want to bet?
Ever since XP, there has been a prominent link on the Start Menu to "The Internet", which opens the current default browser. It's far bigger and more obvious than "Internet Explorer".
No, these users aren't going to have a clue what a browser is, the words "Internet Explorer" will likely mean nothing to them. They might just pick IE because it sounds right -- but they might as easily pick Google Chrome because they know they use Google.
However, I suspect it's far more likely that they'll try to figure out how to get rid of that annoying popup, rather than bothering to actually read it. So, sadly, they might end up with IE just by figuring out that they can close the ballot screen by clicking the X in the upper right.
Rather than making sure that all the components of Windows are installed, that all the crapware is installed, dealing with disks, etc.
Do you know how a disk image works? It's really very little more work to image a hard disk than to just put a brand-new, blank one in there.
You are kidding right? IBM (who had a near total monopoly on computer systems at the time) needed an OS, so MS basically bought DOS from a couple of guys who made it and licensed it to IBM.
True.
DOS was -terrible- but due to IBM's monopoly its what people used,
True -- and that should be a period, not a comma.
when people realized they could build an IBM-compatible machine the clones started coming out and they wanted software compatibility so they licensed DOS too.
See, here's where you're missing a key piece of information:
Microsoft managed to sell DOS to IBM... but not as an exclusive arrangement. Because of this, Microsoft could then turn around and sell DOS (and later Windows) to any IBM clone who wanted it.
Without this, it wouldn't have mattered -- those IBM clones would've been exactly as successful as Pystar.
Microsoft was in no way a major player, the events that happened would have happened without Microsoft's assistance. It was inevitable that the IBM PC would be reverse engineered and cheaper clones could be produced.
Impossible to say -- but it does seem likely that IBM would have released their own OS, and one which was licensed only for use on IBM machines. The evidence is obvious -- IBM did have a PC OS at one point (OS2), and if you look at how their mainframe OSes are licensed, it wouldn't be surprising at all for it to be licensed for IBM PCs only.
At that point, it could very well be that Apple would've won. The biggest reason they didn't is that they discouraged clones, while IBM allowed them -- thus, PC hardware got cheaper and cheaper, culminating in Apple's move to Intel because the Power architecture simply couldn't compete. Power may have been superior technology, but Intel was cheaper, mass-produced, and evolving faster.
You'll notice I snipped this part. That's because it deserves special ridicule:
(thankfully there was no DMCA or other restrictive laws back then)
"Restrictive" like, I don't know, copyright itself? Software became copyrightable in 1980. The initial release of MS-DOS was in 1981. And copyright is all you need to sell a "license to use", rather than a mere copy of the software.
As it stands, the above would be untrue, and nobody cares that some dev somewhere decides to kill his business in order to stick it to the man.
You'd have a point, if he had a business to begin with. Thanks to the App Store's psychotic review process, he didn't.
Either that, or they think the games aren't important...
There's something specific. I can work with that.
What about a web browser isn't suitable for games?
Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.
Depends what X is, but it doesn't sound particularly hard.
for other phones which use physical buttons, not having access to them makes for a significant decrease in usability.
So expose them as keystrokes, which web apps do have access to.
Even on the iPhone: can a web app make proper use of multi-touch?
I'm not sure, though apparently Firefox Mobile exposes even the accelerometer to the web app.
A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work.
That's only if you assert Javascript isn't appropriate for this. I disagree. As you say:
The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.
Except that you still have the advantage of write-once, install anywhere, automatic sandboxing, updates, and everything else.
If you think the only advantage of a web app is being able to write it in your own language on the server-side, you have wildly missed the point.
Since when does nlite remove bloat from the kernel?
I doubt very much there's any intelligent pro-Sony, pro-OSS person.
Yes, the PS2 had Linux. It cost $200, and included a hard drive. There was no other legal way to do it. But hey, at least it had full access to the hardware.
The PS3 also has Linux, but this time, they've crippled it by running it in a hypervisor -- that is, a virtual machine.
Linux people also tend to be anti-DRM. Sony has, among other things, created DVDs which couldn't be played in most computers (or many Sony DVD players) by deliberately breaking the spec in a way they assumed would apply only to PCs, and released music CDs with a Windows rootkit installed on autoplay which makes your computer measurably less secure and slower, all in order to prevent you from "unauthorized" use, which apparently includes ripping.
I mean, I'm sure there are some people who are simultaneously Linux fanboys and Sony fanboys, but it's a position that doesn't make much sense.