Actually, it's not that simple. The DNS compression scheme is horrendous, although that can be easily isolated. Most of the complexity of DNS servers come from the 1) caching, recursive logic for client-side servers, 2) automating zone transfers, 2) various schemes for avoiding DoS attacks. Dedicated servers like NSD and unbound, which either server a zone _or_ implement recursive lookups for clients, can be a little simpler.
I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh that would do the same job without adding all that extra code and the extra attack surface that comes along with it. Heck, with access to platform-specific file system event APIs, you could probably come up with something that worked a lot better, up to and including near-instantaneous updates. That entire feature just seems like pure bloat, and that's coming from somebody who actually uses zone transfers....
Swift isn't going to make it so "anybody can write apps." That is something that's been tried for decades, with things like drag-and-drop programming. SQL was originally intended for non-programmers. It doesn't work, because the difficulty of programming isn't the syntax. The difficulty of programming is logic.
While true, the danger exists that making the syntax easier will encourage more people who don't understand logic to try to write code anyway, usually with disastrous results. Maybe it's the UNIX greybeard in me, but I've always seen the complexity of language as sort of a "you must be this tall to ride" bar, limiting the amount of damage that clueless people can cause.
And it isn't just that the software that new programmers create is usually bad. It also clogs the marketplace with low-quality apps. The more bad apps people write, the harder it will be for well-written new apps to gain footing, because they'll start out with several times as many poorly written apps ahead of them in their sales ranking.
But the biggest problem with making it easier to write code is that every step down that path requires ever-increasing resources. Right now, it takes about an order of magnitude more effort to write a beginning programming guide than to write a programming guide for experienced programmers, even for a moderately complex technology. And that's if you assume that people understand basic logic, control flow, etc. If you go one step beyond that and try to make it practical for non-programmers to write code, you'll spend two or three years writing a good, solid introductory textbook. And I have yet to see any evidence suggesting that any significant percentage of those folks will be able to write decent code even after reading such a book.
The kernel is stable not just because it has to be, but also because it scares people away until they are reasonably competent at programming. The web is filled with bad code because it doesn't. IMO, apps should be more like the former than the latter. Just my $0.02.
Neither of those provides any mechanism for downsampling an image before uploading it. In fact, from a same-origin security model perspective, JS code isn't even supposed to be able to access the image data before uploading it, though I think they've left some holes where devs can get around that....
That's why I don't want every random site creating its own app. When I said those words, it was in the context of a general-purpose mobile app, not a niche app for a single small website.
Web browsers on mobile devices don't provide facilities for downsampling the images, though, which makes standalone apps rather useful for sites that rely on photo uploading over slow cellular connections.
Sure there is. That's exactly what RSS [wikipedia.org] was made to do. Not only can you visit a site, get a feed, and add it yourself, but there are also applications that curate and categorize popular RSS feeds so that you can search for and add them without having to visit the websites first.
The problem is that RSS is one-directional. If I want to post, I still have to go back to a browser window and use whatever random, horrible, non-mobile-friendly interface the site designers came up with. And posting is usually the part where a native app would be beneficial; the reading part is easy by comparison....
And despite what you say, the facebook app is pretty much standard on every user's smart phone, and the app only shows content from facebook...
... and is used exclusively by people who have accounts on the site. That's a completely different usage model than just going to a website and browsing it, which is to say that you didn't really contradict my main point with that example.
Facebook is also a bit of an exception because of the sheer amount of time that many people spend on it, the potential benefits of tighter integration with the operating system (background notifications), etc.
But for every exception, there are a thousand non-exceptions. Even though I have the FB app installed, I wouldn't really consider installing a Slashdot app; the way I interact with the site is completely different, with my FB interaction being a lot more active, and involving a lot more photo uploads and other such activities that web browsers do pretty badly in the mobile world.
During your rant, I couldn't help but think, 'But they DO have a standardized app for accessing all the websites', and it's called the browser!
The problem is, mobile devices don't handle web forums very well. Web designers don't design their themes with mobile devices in mind, resulting in text that's too small to read, text entry fields that are too wide for the screen, etc. That's not true for every site, but it is pretty common.
An actual native app, by contrast, is likely to be designed by people who actually understand the platform and its limitations, its screen size, etc. So potentially, if done properly, it can produce a much better user experience than a browser is likely to produce (though a browser could produce a similarly good experience if all the web designers took the time to design their sites properly for mobile devices... and I want a pony...).
Not really. My TV takes uncompressed data. Once an encoder is available, the only things that matter these days are whether the following things support the codec:
Chrome
Safari
Firefox
iOS
Android
YouTube
to a lesser extent, OS X, Windows, and Internet Explorer
If you cover those, all other clients of the codecs are lost in the noise, so it is probably safe to use it on your own site for your own content.
It doesn't really matter at all whether the codec used to encode the content for delivery is the same as the codec used to encode it during production. In fact, I would seriously hope that 100% of video production is being done with a higher quality codec than the low-bitrate crap that is being used to deliver content over the 'net. Therefore, whether Mitsubishi et al choose to support a codec or not is mostly irrelevant.
In practice, only three companies actually need to work together to make such a patent-free codec happen: Apple, Microsoft, and Google. Firefox would quickly adopt any patent-free codec that those three got behind. That makes the entire rest of the industry pretty much completely irrelevant. Those three companies could mandate a transition to a new, patent-free codec, and the entire world would practically trip over themselves to make it happen.
So no, those industrial giants aren't really a problem. In fact, they aren't even relevant in the grand scheme of codecs except to the extent that the big three graciously allow them to be.
It is truly an epic fail to believe that some random visitor to your website is going to want to install your app just to read a piece of content—particularly if that user got there through a Google search. Yet for some reason, just about every forum out there pops up one of these idiotic app interstitials when I try to view some random post on their site. I didn't go there because I want to be a regular visitor to the site, which means I sure as h*** don't want to install their app just to read the tiny piece of content that may or may not even contain the information I need to do whatever I'm trying to get done.
The right time to ask a user to install an app is when the user creates an account on the site. Up until that point, the user is probably an infrequent visitor and is unlikely to want to install the app. Even at that point, the user may not want to install the app, but at least there's some nonzero possibility that he or she might.
Of course, the real train wreck is that there's no standard for making websites' contents available for app use, which would allow a user to install one reader that can read content on any of the dozen sites that he or she might be interested in. There's really no chance of me installing an app that only lets me read content from one website, because A. it is unlikely to be much better than viewing the website (because probably the same people designed it), and B. I already have more apps than I can deal with anyway. But if every website I visit standardized on a feed scheme, along with a common authentication system and a common reply system, I could see myself installing a single app that worked with all of them.
Don't like the licensing terms? Don't use H.265...
Better: Work together with like-minded companies to create a competing standard that is designed specifically to avoid patents, and license it royalty-free.
It's not quite fair to exclude the cost of your ISP or wireless plan. Whether you "need it anyway" for other purposes or not, you still can't ACTUALLY get Netflix for only $12 month unless your ISP is free (and fast enough to support decent HD streaming).
Well, you can do their DVD service for $8, but yes, for their streaming service, you do have to have an Internet connection. Of course, if you have a smartphone, at least in the U.S., your cell service provider will likely require you to have a data plan anyway, so these days it's hard to not have a connection that you could potentially use for watching Netflix if you wanted to. (Whether that data plan would cost you more money if you watched Netflix all day is another matter, of course.)
Except Google didn't offer it to the public. It is an unpublished API that is and was unsupported for external use.
Is this the same API that Safari, Chrome, Firefox, etc. use for autocompleting search queries in their search boxes? If so, and if they disable it, there are going to be a lot of unhappy people, and by a lot, I mean literally every human being who uses a web browser.
I'm not sure how Netflix, et al, is so much better in that respect.
It costs $12 a month versus a hundred or so. You're still not getting better programming, but at least you're paying a tenth as much to not get better programming.:-)
The reality is that most email list servers were set up a decade ago by somebody who hasn't touched it since. Expecting them to all upgrade their software to accommodate some new scheme is ridiculous enough to qualify for one of those "Your solution is impractical because" posts with the "it requires broad deployment on hundreds of thousands of servers, performed by tens of thousands of unpaid volunteers" checkbox checked.
Unlike the people who set up most of those email list servers, the Google employees who set up their spam filters are getting paid to do a good job of filtering. If you expect the problem to actually get fixed in this century, guess who will have to do the work to prevent those messages from getting flagged as spam....
Besides, mailing lists are very obviously different from spam in several critical ways. For one, you send email to them regularly. That should weigh heavily against the server being categorized as a spam server, and should therefore weigh heavily in favor of trusting mail delivered by that server, regardless of signing or lack thereof. For another, the posts are part of an ongoing discussion, which means the subject lines are closely related to the subject lines of other email messages sent by other people that didn't trip the spam filter. That should also weigh heavily against such a message being marked as spam. For a third, the email messages contain fragments of quoted comment from other messages in the thread. For a fourth, a Bayesian classifier or similar, when applied to the message, should strongly show similarity to other messages that are not flagged as spam, and should show very little similarity to messages that are.
If, in spite of such overwhelming evidence that the message is not spam, your spam filters still flag it as spam solely because of an arbitrary technological measure like DKIM that is not broadly supported by remailers, you're doing it wrong.
Using a beefier GPU isn't necessarily the wrong choice, assuming you can sink enough heat. From my perspective, the critical questions are how it compares in terms of power per watt and minimum idle power.
For example, consider two GPUs. The faster chip uses 80% more power at full throttle, but gives you twice the computing power. So if you need to do 10 units of work, the slower ship will take 10 seconds to do it, and the second one will take five seconds, but will use the same amount of power as the first chip would use in 9 seconds. Assuming the idle power on the faster chip doesn't eat up all the gains, you'll end up with better battery life by using the faster chip.
Unfortunately, I couldn't find full specs for the Nvidia Quadro K620M, so I can't say for sure whether that's the reason for that design decision.
Semi-segregated. At least in my experience, if there are passengers in coach coming in whose luggage won't fit in their overhead bins, the flight attendants will usually put the bags into empty bin space in first class, rather than going through the hassle of gate-checking it.
True, but once all the flights are flown by computer (we'll be there before you know it), the takeoffs and landings probably won't be nearly as high a percentage of crashes. A computer won't cut the wrong engine when one flames out, nor will it hesitate in throttling up the other one. It won't clip the edge of the barrier at the end of the runway. And so on.
That said, I'd kill to watch an aborted takeoff where sections of the plane get boosted a hundred feet straight up into the air, then deploy parachutes explosively. That would be pretty cool.
No, MacBook Pros claim 9 hours of typical battery life. And when I'm just doing word processing, I get about that. Unfortunately, when I run real power-user apps, like Photoshop, Finale (music notation), Xcode, etc., I'm lucky if I get three hours.
Don't get me wrong, the effort that Apple has put into optimizing their apps and the OS itself is a very good thing, and it helps a lot for typical users. With that said, for what I do with my Mac, I'd trade this retina MBP for a thicker model in a heartbeat if Apple would stick the retina guts into a pre-retina MacBook Pro case and fill all the extra space with extra batteries (ideally with about four independent packs discharging approximately sequentially, but in random order, to maximize reliability in the event of a pack failure, but I digress).
And no, I don't care that it would be thicker or that it would weigh more. I carried around a Pismo with dual batteries for half a decade. It really doesn't matter that much.
Trademarks may stink, but they're the law. If you come up with an app you want to protect in a business segment, the ONLY way to protect your use of that app name in stores and (if you managed to acquire it) the domain name is to get yourself a REGISTERED trademark on it for that market segment. You can do it yourself for a few hundred dollars (US only). Without it, others can make a [poor] copy of your work, legally take your domain name away, have your app removed from stores, and cause all sorts of problems.
That's not true, at least in the United States (even for "famous trademarks"). If you are using a name in commerce and can document that you were using it prior to when the trademark was registered, your use of the trademark is considered to have priority, at least within the geographic region in which you were previously using it, and within the same category of products.
Most airlines load coach from back to front, though the ideal is probably back to front and outside to inside. And ideally, they would load people almost precisely in row order—basically use the whole Southwest numbered boarding thing, but with seat assignments. Otherwise, it is still pretty inefficient for the reasons you mention. I don't know why nobody does that.
As for why they load first-class first, that's easy. If they don't, there's a very good chance that first-class passengers would find themselves with insufficient overhead bin space for their stuff. If you paid three prices for a ticket and then they forced you to check your bag, you'd be seriously angry.
The reason some aircraft have a separate entrance for first-class is efficiency. When you have that many people boarding at once, you can't realistically load them all through one entrance. An ideal arrangement would put that second door in the middle of coach, so that half of them go forwards and the other half go backwards, rather than at the front of coach, but even just separating first/business from coach reduces the number of people using the coach door significantly. I realize that a center-boarding arrangement would be much harder to achieve (with the wing being in the way and all), but it would be nice if they could find a way.
I've been asking for compartmentalized planes for years, for two. Speed of boarding is one, but not the big one. Safety is the other. Imagine never having a single death from plane crashes except the ones that caused by sudden failures or pilot errors during takeoff and landing.
With a compartmentalized plane, if the airframe fails, the pilot could point it in the general direction of an uninhabited area, cut the engines, push the ejection button, calmly exit the cockpit into the front passenger compartment, strap into the jump seat, and wait. A few moments later, a series of explosive bolts would detonate, severing each compartment from the airframe a few seconds apart, and a parachute would deploy, thus bringing the compartment safely to the ground, with no lives lost.
You could even make deployment be automatic under certain circumstances, such as depressurization, descending below a present altitude without manually overriding it for landing, etc., thus saving lives in situations where the pilot becomes incapacitated. And you could put an emergency override on the outside of the cockpit to eliminate any possibility of mass-murder-suicide by airplane. (The suicide part might still happen, but at least an errant pilot couldn't take out everyone on the plane, too.)
In my experience, the first-class seat may or may not recline any farther than the coach seats do. You get more legroom, and more width, but you're often still basically sitting upright even with the seat fully reclined. Of course, it depends on the aircraft and how they've configured it.
For every plane used for overnight flights, they really need to take out about every second or third row, spread the seats proportionally, and make them recline. Crank up the ticket price proportionally. There's really no excuse for being unable to sleep on a redeye.
Even better, they could make it easier to change the configuration, like you can with a passenger van. The first time the plane is on the ground after 8:00 p.m., the ground crew could walk in, push a lever, slide the seat forward, lift it up, and carry it off the plane. The flight attendants could come along behind them and switch the lever that allows the remaining seats to recline further.
Alternatively, they could also make a section of the under-plane storage available to make the passenger compartment taller, then add Amtrak-style fold-down beds. At a particular time, you fold down the upper berths and the lower ones slide together in pairs, forming the bottom berths.
Slashdot Mirror
I've never understood why DNS servers bother with zone transfers. These days, it would take an average admin three minutes to toss together something involving a cron job, rsync, and ssh that would do the same job without adding all that extra code and the extra attack surface that comes along with it. Heck, with access to platform-specific file system event APIs, you could probably come up with something that worked a lot better, up to and including near-instantaneous updates. That entire feature just seems like pure bloat, and that's coming from somebody who actually uses zone transfers....
Wow. They've really opened up filesystem access since I last looked. So much for same origin policies....
While true, the danger exists that making the syntax easier will encourage more people who don't understand logic to try to write code anyway, usually with disastrous results. Maybe it's the UNIX greybeard in me, but I've always seen the complexity of language as sort of a "you must be this tall to ride" bar, limiting the amount of damage that clueless people can cause.
And it isn't just that the software that new programmers create is usually bad. It also clogs the marketplace with low-quality apps. The more bad apps people write, the harder it will be for well-written new apps to gain footing, because they'll start out with several times as many poorly written apps ahead of them in their sales ranking.
But the biggest problem with making it easier to write code is that every step down that path requires ever-increasing resources. Right now, it takes about an order of magnitude more effort to write a beginning programming guide than to write a programming guide for experienced programmers, even for a moderately complex technology. And that's if you assume that people understand basic logic, control flow, etc. If you go one step beyond that and try to make it practical for non-programmers to write code, you'll spend two or three years writing a good, solid introductory textbook. And I have yet to see any evidence suggesting that any significant percentage of those folks will be able to write decent code even after reading such a book.
The kernel is stable not just because it has to be, but also because it scares people away until they are reasonably competent at programming. The web is filled with bad code because it doesn't. IMO, apps should be more like the former than the latter. Just my $0.02.
Neither of those provides any mechanism for downsampling an image before uploading it. In fact, from a same-origin security model perspective, JS code isn't even supposed to be able to access the image data before uploading it, though I think they've left some holes where devs can get around that....
So is a web browser, which is exactly my point.
That's why I don't want every random site creating its own app. When I said those words, it was in the context of a general-purpose mobile app, not a niche app for a single small website.
Web browsers on mobile devices don't provide facilities for downsampling the images, though, which makes standalone apps rather useful for sites that rely on photo uploading over slow cellular connections.
The problem is that RSS is one-directional. If I want to post, I still have to go back to a browser window and use whatever random, horrible, non-mobile-friendly interface the site designers came up with. And posting is usually the part where a native app would be beneficial; the reading part is easy by comparison....
... and is used exclusively by people who have accounts on the site. That's a completely different usage model than just going to a website and browsing it, which is to say that you didn't really contradict my main point with that example.
Facebook is also a bit of an exception because of the sheer amount of time that many people spend on it, the potential benefits of tighter integration with the operating system (background notifications), etc.
But for every exception, there are a thousand non-exceptions. Even though I have the FB app installed, I wouldn't really consider installing a Slashdot app; the way I interact with the site is completely different, with my FB interaction being a lot more active, and involving a lot more photo uploads and other such activities that web browsers do pretty badly in the mobile world.
The problem is, mobile devices don't handle web forums very well. Web designers don't design their themes with mobile devices in mind, resulting in text that's too small to read, text entry fields that are too wide for the screen, etc. That's not true for every site, but it is pretty common.
An actual native app, by contrast, is likely to be designed by people who actually understand the platform and its limitations, its screen size, etc. So potentially, if done properly, it can produce a much better user experience than a browser is likely to produce (though a browser could produce a similarly good experience if all the web designers took the time to design their sites properly for mobile devices... and I want a pony...).
Not really. My TV takes uncompressed data. Once an encoder is available, the only things that matter these days are whether the following things support the codec:
If you cover those, all other clients of the codecs are lost in the noise, so it is probably safe to use it on your own site for your own content.
It doesn't really matter at all whether the codec used to encode the content for delivery is the same as the codec used to encode it during production. In fact, I would seriously hope that 100% of video production is being done with a higher quality codec than the low-bitrate crap that is being used to deliver content over the 'net. Therefore, whether Mitsubishi et al choose to support a codec or not is mostly irrelevant.
In practice, only three companies actually need to work together to make such a patent-free codec happen: Apple, Microsoft, and Google. Firefox would quickly adopt any patent-free codec that those three got behind. That makes the entire rest of the industry pretty much completely irrelevant. Those three companies could mandate a transition to a new, patent-free codec, and the entire world would practically trip over themselves to make it happen.
So no, those industrial giants aren't really a problem. In fact, they aren't even relevant in the grand scheme of codecs except to the extent that the big three graciously allow them to be.
It is truly an epic fail to believe that some random visitor to your website is going to want to install your app just to read a piece of content—particularly if that user got there through a Google search. Yet for some reason, just about every forum out there pops up one of these idiotic app interstitials when I try to view some random post on their site. I didn't go there because I want to be a regular visitor to the site, which means I sure as h*** don't want to install their app just to read the tiny piece of content that may or may not even contain the information I need to do whatever I'm trying to get done.
The right time to ask a user to install an app is when the user creates an account on the site. Up until that point, the user is probably an infrequent visitor and is unlikely to want to install the app. Even at that point, the user may not want to install the app, but at least there's some nonzero possibility that he or she might.
Of course, the real train wreck is that there's no standard for making websites' contents available for app use, which would allow a user to install one reader that can read content on any of the dozen sites that he or she might be interested in. There's really no chance of me installing an app that only lets me read content from one website, because A. it is unlikely to be much better than viewing the website (because probably the same people designed it), and B. I already have more apps than I can deal with anyway. But if every website I visit standardized on a feed scheme, along with a common authentication system and a common reply system, I could see myself installing a single app that worked with all of them.
Better: Work together with like-minded companies to create a competing standard that is designed specifically to avoid patents, and license it royalty-free.
Obligatory xkcd.
Well, you can do their DVD service for $8, but yes, for their streaming service, you do have to have an Internet connection. Of course, if you have a smartphone, at least in the U.S., your cell service provider will likely require you to have a data plan anyway, so these days it's hard to not have a connection that you could potentially use for watching Netflix if you wanted to. (Whether that data plan would cost you more money if you watched Netflix all day is another matter, of course.)
Is this the same API that Safari, Chrome, Firefox, etc. use for autocompleting search queries in their search boxes? If so, and if they disable it, there are going to be a lot of unhappy people, and by a lot, I mean literally every human being who uses a web browser.
It costs $12 a month versus a hundred or so. You're still not getting better programming, but at least you're paying a tenth as much to not get better programming. :-)
The reality is that most email list servers were set up a decade ago by somebody who hasn't touched it since. Expecting them to all upgrade their software to accommodate some new scheme is ridiculous enough to qualify for one of those "Your solution is impractical because" posts with the "it requires broad deployment on hundreds of thousands of servers, performed by tens of thousands of unpaid volunteers" checkbox checked.
Unlike the people who set up most of those email list servers, the Google employees who set up their spam filters are getting paid to do a good job of filtering. If you expect the problem to actually get fixed in this century, guess who will have to do the work to prevent those messages from getting flagged as spam....
Besides, mailing lists are very obviously different from spam in several critical ways. For one, you send email to them regularly. That should weigh heavily against the server being categorized as a spam server, and should therefore weigh heavily in favor of trusting mail delivered by that server, regardless of signing or lack thereof. For another, the posts are part of an ongoing discussion, which means the subject lines are closely related to the subject lines of other email messages sent by other people that didn't trip the spam filter. That should also weigh heavily against such a message being marked as spam. For a third, the email messages contain fragments of quoted comment from other messages in the thread. For a fourth, a Bayesian classifier or similar, when applied to the message, should strongly show similarity to other messages that are not flagged as spam, and should show very little similarity to messages that are.
If, in spite of such overwhelming evidence that the message is not spam, your spam filters still flag it as spam solely because of an arbitrary technological measure like DKIM that is not broadly supported by remailers, you're doing it wrong.
Using a beefier GPU isn't necessarily the wrong choice, assuming you can sink enough heat. From my perspective, the critical questions are how it compares in terms of power per watt and minimum idle power.
For example, consider two GPUs. The faster chip uses 80% more power at full throttle, but gives you twice the computing power. So if you need to do 10 units of work, the slower ship will take 10 seconds to do it, and the second one will take five seconds, but will use the same amount of power as the first chip would use in 9 seconds. Assuming the idle power on the faster chip doesn't eat up all the gains, you'll end up with better battery life by using the faster chip.
Unfortunately, I couldn't find full specs for the Nvidia Quadro K620M, so I can't say for sure whether that's the reason for that design decision.
Semi-segregated. At least in my experience, if there are passengers in coach coming in whose luggage won't fit in their overhead bins, the flight attendants will usually put the bags into empty bin space in first class, rather than going through the hassle of gate-checking it.
True, but once all the flights are flown by computer (we'll be there before you know it), the takeoffs and landings probably won't be nearly as high a percentage of crashes. A computer won't cut the wrong engine when one flames out, nor will it hesitate in throttling up the other one. It won't clip the edge of the barrier at the end of the runway. And so on.
That said, I'd kill to watch an aborted takeoff where sections of the plane get boosted a hundred feet straight up into the air, then deploy parachutes explosively. That would be pretty cool.
No, MacBook Pros claim 9 hours of typical battery life. And when I'm just doing word processing, I get about that. Unfortunately, when I run real power-user apps, like Photoshop, Finale (music notation), Xcode, etc., I'm lucky if I get three hours.
Don't get me wrong, the effort that Apple has put into optimizing their apps and the OS itself is a very good thing, and it helps a lot for typical users. With that said, for what I do with my Mac, I'd trade this retina MBP for a thicker model in a heartbeat if Apple would stick the retina guts into a pre-retina MacBook Pro case and fill all the extra space with extra batteries (ideally with about four independent packs discharging approximately sequentially, but in random order, to maximize reliability in the event of a pack failure, but I digress).
And no, I don't care that it would be thicker or that it would weigh more. I carried around a Pismo with dual batteries for half a decade. It really doesn't matter that much.
That's not true, at least in the United States (even for "famous trademarks"). If you are using a name in commerce and can document that you were using it prior to when the trademark was registered, your use of the trademark is considered to have priority, at least within the geographic region in which you were previously using it, and within the same category of products.
Most airlines load coach from back to front, though the ideal is probably back to front and outside to inside. And ideally, they would load people almost precisely in row order—basically use the whole Southwest numbered boarding thing, but with seat assignments. Otherwise, it is still pretty inefficient for the reasons you mention. I don't know why nobody does that.
As for why they load first-class first, that's easy. If they don't, there's a very good chance that first-class passengers would find themselves with insufficient overhead bin space for their stuff. If you paid three prices for a ticket and then they forced you to check your bag, you'd be seriously angry.
The reason some aircraft have a separate entrance for first-class is efficiency. When you have that many people boarding at once, you can't realistically load them all through one entrance. An ideal arrangement would put that second door in the middle of coach, so that half of them go forwards and the other half go backwards, rather than at the front of coach, but even just separating first/business from coach reduces the number of people using the coach door significantly. I realize that a center-boarding arrangement would be much harder to achieve (with the wing being in the way and all), but it would be nice if they could find a way.
I've been asking for compartmentalized planes for years, for two. Speed of boarding is one, but not the big one. Safety is the other. Imagine never having a single death from plane crashes except the ones that caused by sudden failures or pilot errors during takeoff and landing.
With a compartmentalized plane, if the airframe fails, the pilot could point it in the general direction of an uninhabited area, cut the engines, push the ejection button, calmly exit the cockpit into the front passenger compartment, strap into the jump seat, and wait. A few moments later, a series of explosive bolts would detonate, severing each compartment from the airframe a few seconds apart, and a parachute would deploy, thus bringing the compartment safely to the ground, with no lives lost.
You could even make deployment be automatic under certain circumstances, such as depressurization, descending below a present altitude without manually overriding it for landing, etc., thus saving lives in situations where the pilot becomes incapacitated. And you could put an emergency override on the outside of the cockpit to eliminate any possibility of mass-murder-suicide by airplane. (The suicide part might still happen, but at least an errant pilot couldn't take out everyone on the plane, too.)
In my experience, the first-class seat may or may not recline any farther than the coach seats do. You get more legroom, and more width, but you're often still basically sitting upright even with the seat fully reclined. Of course, it depends on the aircraft and how they've configured it.
For every plane used for overnight flights, they really need to take out about every second or third row, spread the seats proportionally, and make them recline. Crank up the ticket price proportionally. There's really no excuse for being unable to sleep on a redeye.
Even better, they could make it easier to change the configuration, like you can with a passenger van. The first time the plane is on the ground after 8:00 p.m., the ground crew could walk in, push a lever, slide the seat forward, lift it up, and carry it off the plane. The flight attendants could come along behind them and switch the lever that allows the remaining seats to recline further.
Alternatively, they could also make a section of the under-plane storage available to make the passenger compartment taller, then add Amtrak-style fold-down beds. At a particular time, you fold down the upper berths and the lower ones slide together in pairs, forming the bottom berths.