Not quite the same thing. What VW did was recognize the test and change operating modes only during testing. What Samsung did was build a "Home" mode for optimum energy savings and other modes (including changing settings from the defaults in Home mode to give a custom mode) that optimized viewing experience at the expense of power use. The EU's tests use "Home" mode and don't test any other modes, while most consumers immediately adjust the TV for optimum viewing regardless of power consumption, so of course TVs in normal use use more power than their test scores indicate. But the TV doesn't change anything on it's own and it doesn't run any differently during the test than it does in the same mode in normal use, it's just that the EU didn't bother testing the TV in the configuration most consumers are going to set it to. Myself, I'd run the test in every mode the TV has and compare results because you know consumers aren't going to ignore additional modes.
I'm surprised this scam still works today. All of my cards automatically reject purchases where the shipping address isn't the billing address of my card. I can add addresses to the valid list, but I have to do it beforehand through their web site or through customer service. That should shut this kind of scam down.
Or the other obvious change of, instead of having the merchant charge my card, have me tell my bank/issuer to pay the merchant. Then the merchant never needs to know my card number and it's a lot harder for scam artists to operate.
How about an ad blocker that charges advertisers per view to let their ads be seen, and pays users a portion of that (say split it 10% to the blocker's developer, half the remainder to the site and half to the user) if they allow the ads to be shown to them. If the advertiser wants more views, they can either a) make more interesting ads that people actually want to see or b) offer more money for people's attention.
Can you afford to walk away from your job right this minute? Knowing you'll get no unemployment compensation, no welfare, no assistance of any kind? It's one thing to voluntarily follow orders, quite another when the person giving the orders is holding the welfare of your family hostage against your good behavior. In my book people who refuse to recognize this are complicit with management in the act, they directly help management perpetuate the conditions that let management get away with these crimes.
Exactly. The basic problem is a lack of management ethics. Management considers it perfectly acceptable to cheat like this, knowing they're cheating and breaking the law while doing so, and they expect everyone in the organization to follow along. Management also considers it perfectly acceptable to lie about why they let someone go, rather than simply fire them for disobeying orders (which would leave the employee free to say exactly what orders they disobeyed) they find some other innocuous excuse and leave the employee no real way to respond when asked by a future employer why they were terminated. Until management ethics is fixed, it won't be possible to do anything about engineering ethics.
I'd go limp: "We'll comply with your request. Please send us the contact information for the service that you'll accept as authoritative for whether or not a request from a particular IP address originates in France or not. We'll also require a binding agreement that the determination of this service cannot be contested by either Google or the French government, and that if any third party demonstrates that the service made an incorrect determination use of that service will be discontinued and the French government shall not demand compliance from Google until the French government has selected a new authority. Until we are in receipt of this information and agreement, Google will unfortunately be unable to operate the French-localized Google site and will be unable to serve search results for France or any French entity or person. Have a nice day.".
First rule: have facilities capable of running your business in more than one location. Everywhere is susceptible to disaster of one sort or another, but if you pick areas far apart that aren't geographically similar they probably won't both suffer disasters at the same time.
Second rule: the probability of disaster taking out your main facilities is 100%. It will happen. The only question is exactly when it'll happen, and the only constant in the answer is that it won't be at a good time. If anyone in your organization doesn't like this, remind them that reality doesn't really care what they like.
I think there'll still be apps, but things will evolve to having apps in parallel with APIs. For example, for an appointment-management service there'll be an app (or more than one, eg. a webapp for desktop use and a mobile app or mobile-optimized webapp for phone/tablet use) for customers who just want to let clients make appointments and want to be able to manage those appointments and don't need a lot of customization. There'll also be API access that would let customers get at the basic operations (with appropriate authentication and filtering for safety) that the apps themselves use so more sophisticated customers can use the service's functionality through a custom interface. It won't be an exclusive-or situation either, a customer may have their Web developer use the API to integrate setting up appointments into their own client web site while their staff use the standard webapp to manage appointments.
Neither the app nor the API will likely be free, either. The customer's clients won't pay in the above scenario, but aside from a trial period the customer would have to pay for access to the service (the amount probably depending on their usage and what features they want access to). We're about to hit a point where merely being able to get a huge userbase won't be considered valuable, you'll need to have a feasible roadmap for getting a revenue stream from your users. A thousand users each paying a monthly subscription will be more valuable than a million users not paying you anything. And frankly it's a lot easier to maintain paying users if you start them out as paying users.
It's complete bullshit, at least at the current state of the art. It's not a new idea either. People who aren't actual developers have been pushing this idea of drag-and-drop "programming" since the early 80s at least. 30 years of work, and the most they've managed are tools to automate generating the boilerplate code to lay out UI elements in the software's interface. They haven't even managed to automate moving the values from the UI fields into the software's internal objects/variables, the task's just too complex for their tools. So, why would anyone thing they'll overnight overcome all the problems and hurdles in their way and suddenly make orders of magnitude more progress in the next couple-three years than they have in the last 3 decades?
Well, #1 and #3 come under technical "Can we do it?", at least the parts where the company has the technical ability to switch providers if one goes out of business and to handle connectivity problems (I classify a provider going out of business as just a particularly severe and long-term connectivity problem, communications with their systems is completely down and won't ever be back up). The rest is all business decisions, the same sort business makes about every external vendor the company does business with. Legal issues in particular aren't something IT should be involved in, the company pays real lawyers to advise the business on that sort of thing and if I as a techie know more about the legal aspects than the lawyers something is really wrong.
The first call comes from the technical people, and answers the question "Is the company technically able to move to the cloud, and if not what's required to get it to that point?". Once you've got that covered, then business can decide whether it makes sense to move and whether they want to invest what it'll take to make it happen. If it isn't technically possible it doesn't matter how much business wants it, and business can't make a determination about investing what's needed to make it possible if they don't know how much investment it'll take. You can't make a cost/benefit decision if you don't know the cost.
The problem isn't the systems. It's 50 years of business logic embedded in the code that runs those systems. Half of it was never documented, because management needed it Right Now and once it was working they needed the developers on another project they also needed Right Now. Of the half that is documented, most of it has undocumented special cases in it and nobody has a clue whether they're needed anymore or not. And this is where the sticking point is, because you can't configure a canned solution to do the job if you don't know what the job is and there's always parts of it so arcane that the canned solutions just won't handle it (this is usually the final nail in the coffin of SAP projects that actually went long enough to get the basics working).
So the decision's more often whether to spend a million dollars on a new system and keep 100 developers, analysts and the like at $100K/year working for 8-10 years on the new system and keep those 10 COBOL developers working for the same period (because you need the old system working until the new one's at least mostly ready), or just keep the 10 COBOL developers working.
"...it's significant that someday a large portion of the world's traffic will flow through networks controlled by governments that are, at least to some extent, hostile to the core values of Western democracies."
And some of those will be the governments of Western democracies. That's the truly maddening part.
The basic flaw is worse. They didn't just run one test, find the results they wanted and go with it. They ran a test with only an idea of what they wanted, then took all the results they got and picked out ones that were positive for conditions or treatments they could go with. It's like going into a test for a drug to treat heart attacks, finding that it doesn't do anything for heart attacks but does seem to lower cholesterol levels, and announcing that the trials of your new cholesterol medication were positive.
Having to declare up front what their goals are destroys the ability to cherry-pick like this. What we're seeing with the drop in positive results isn't so much the difference in clinical effectiveness of the drugs but the dragging into the spotlight of the pharma companies' ability to predict what their drugs will do and how well they'll do them. There's a very interesting blog here that covers a lot of this, and one conclusion that keeps coming up again and again is that medical biochemists and researchers don't really have a good way of predicting from lab results what a compound will do in a live human. It also highlights fairly often how the drug companies will keep pushing a drug through trials even though the results aren't encouraging. It's a common attitude in business and finance, that now that you've invested this much money in something you have to get some return out of it to justify the cost. It's also a common failing in gambling, the belief that now that you're in the hole you have to dig yourself out somehow. But in gambling, if you're holding a bad hand your best bet is to fold. Don't worry about how much you've already got in the pot, it's already lost. Fold and cut your losses before you throw any more money away. Drug companies are notoriously bad at making that decision to walk away. They're also notoriously bad at dealing with a field where there aren't many good rules you can follow to get results. MBAs like process and procedure and predictable results, and right now biochemical research is in a situation where the new stuff is all likely out in areas where there isn't a lot of research, there isn't a good map of the territory and you're going to be doing a lot of "poke it with a pointy stick and let's see what it does" work.
His class is focused on HTML/CSS/JS/etc. which means it's not Web design. Design is artwork and layout, for which yes PS is one of the standard tools (and maybe not the best one if, for instance, you're doing Material design for Android access or responsive design where fixed layouts to fit artwork are a no-no). But Web development, using HTML/CSS/JS/etc. to build the mechanics of the site and make it work, generally doesn't require any particular set of tools. In fact Photoshop's a bad fit here because the file formats you're going to need (mostly PNG, especially if you're going to do any sort of transparency) aren't it's native formats and it doesn't really "get" the more exotic technical tricks you'll need the way say the GIMP does.
Do you actually need all the metadata, layers and such in the PSD, or just the image data? If it's just the image data, have the art creators export the relevant parts as PNG or something (not JPEG for gods' sake) and work with that. Or the GIMP will read PSD files up to a point, usually well enough to get the image data, it's only the very complex PSD files that give it fits. If the art people complain, note that just as it's not their job to know the intricacies of HTML5 and CSS and Javascript needed to make a web site work it's similarly not the web mooks' jobs to know the intricacies of Photoshop and "Export as"/"Save as" shouldn't present that many problems.
If you do need layers and such as an integral part of the template, maybe what you need to do is separate the template extraction part of the process. Have a few machines with Photoshop, and the first step is to take the template to those machines and pull it apart to get the imagery needed plus the additional information like gradients and transparency and z-axis position converted from information in the PSD to the numeric values needed for CSS. Then take the results to the Linux systems to do the core work of assembling the web site.
The situation seems ripe for him to file a DMCA notice against all of Columbia's official film sites and materials. He can prove his film existed before Columbia's was even started, and he has Columbia's admission (in their DMCA notice against his work) that their work is similar enough to his for infringement to occur.
Even for a 40+-year-old male offices are too cold most of the time. And in southern Arizona the settings meant you hit a literally 40F+ wall walking out the building door. That isn't healthy. Although if you have to err it's better to have it set on the cool side, people can always add a sweater to stay warmer but you usually can't legally take clothing off if it's too warm.
Well, it'll solve the problem of the system eating them alive in terms of maintenance and support. Now it'll be eating them alive in terms of development costs instead.
No, wait, they'll need to keep the legacy systems running until the new ones are running, so it'll still be eating them alive in terms of maintenance and support too.
Amusingly most home routers already support most of that. #8 isn't feasible, a router doesn't have enough of a view into the traffic to do that kind of thing in real-time. And IMO #9 is better done on the printers. My laser printer's got Ethernet and a built-in print server (actually several, for the different protocols used by different operating systems). The rest is already a standard part of the firmware most router vendors base their own on. It's just that the vendors have disabled/removed a lot of the useful bits, or at least removed any access to them in their UI. Reflash your router with stock DD-WRT and you get pretty much everything you're asking for. Even the firewall. Every device on your network may have a public IPv6 address, but that doesn't mean the firewall will let inbound traffic through to them. The stock settings on mine are to allow established/related traffic through inbound, allow DHCPv6 traffic in to the router only, allow ICMPv6 traffic, and drop everything else. The IPv6 side follows the same rules as the IPv4 side: I can connect out, but nobody else can initiate a connection in. Oh, and for #5 I wouldn't build a big switch in, you aren't going to be rate-limited by the bandwidth to the router so use one LAN port to feed a larger switch that your network hangs off of. That also removes intra-LAN traffic from the router's switch.
Supporting multiple ISPs is an intricate bit of work, but it's mostly an extension of what's done to support the current WAN port. The biggest problem is that with 2 WAN connections you need a routing daemon and it's configuration has to be coordinated with both ISPs and that's going to be a nightmare.
If you don't care about keeping power consumption to a minimum, there's a lot of fun you can have with a mini-ITX or smaller board, a managed switch and an x86_64 build of DD-WRT.
fe80:: prefix, link-local address, used within the network segment for things like autoconfiguration, DHCP, DNS when the router's acting as a caching DNS server.
Public fixed unicast address based on the MAC address (SLAAC, except that Windows 7 and up use a random number rather than the MAC address by default) or assigned by DHCPv6.
One or more temporary unicast addresses, used for a limited time each for outgoing connections to help obscure your fixed address. The privacy gain here is mostly canceled out for consumers by the fact that it's one/64 per subscriber and that/64 doesn't change very often.
That was by design. Leaving 64 bits for the host address lets them use the Ethernet MAC address (the most common hardware address) as the host address, which leaves only the local network prefix needed to complete configuring the interface and that can be gotten via the Router Advertisement protocol on the known link-local network (fe80::/10). And let's see. The public unicast allocation's 2000::/3, with a few exception blocks carved out for things like 6to4 and Teredo. That's roughly 60 bits for the unique network number, or not quite 268.5 thousand 4-billion+ blocks of network addresses. 0000::/3 and e000::/3 are already in use, but that still leaves us with 5 more/3 blocks we can assign for unicast use without conflicting with anything if the 2000::/3 block runs out. So I think that even with some inefficiency that'll hold us for a good while.
So, precisely how again do they suggest sites verify ages? It needs to at least be proof against a minor with an adult's "borrowed" credit card, and it can't require sites to violate the law. This isn't a technical problem here, it's completely independent of the technology. If these politicians want the problem solved, they need to spend some time thinking about how to solve the problem. And yes, "make someone else solve it" is a valid option but only if having the sites apply that solution by making the politicians the "someone else" is also a valid option.
Yeah, I'm thinking of the change from the Win95 Start menu to the Win7 one. Program Manager, however, acted pretty much as the Start button, you opened it and then navigated folders fairly logically (you wanted an application, you opened the Applications folder and looked there). The applications you used all the time you copied to the desktop so you'd have them at your fingertips. Which, I've noticed, is still how people handle common applications, with "copy it to the taskbar" a close second and the two "pin" options vying for a distant third.
And it still remains: even secretaries had no problem grokking how to work Win3.1's desktop and programs.
The total change from the Windows 3.1 Start button to the subsequent Start buttons was making the Start menu a 2-column menu, putting the contents of the former Programs menu in the left pane and putting the rest of the Start menu items in the right pane. That's it. Oh, and making the initial view not show all the Programs items but only a subset, with an extra item at the bottom to show everything in the same form as it was under the Programs menu.
As for Win3.1 being complicated, every secretary I knew managed to get a handle on it within a few days so it couldn't have been that complicated. The only people I know of who couldn't figure out Win3.1 are the ones who to this day need repeated reminders of how to get to anything that's not directly on their desktop, so methinks the problem doesn't lie in Windows.
Slashdot Mirror
Not quite the same thing. What VW did was recognize the test and change operating modes only during testing. What Samsung did was build a "Home" mode for optimum energy savings and other modes (including changing settings from the defaults in Home mode to give a custom mode) that optimized viewing experience at the expense of power use. The EU's tests use "Home" mode and don't test any other modes, while most consumers immediately adjust the TV for optimum viewing regardless of power consumption, so of course TVs in normal use use more power than their test scores indicate. But the TV doesn't change anything on it's own and it doesn't run any differently during the test than it does in the same mode in normal use, it's just that the EU didn't bother testing the TV in the configuration most consumers are going to set it to. Myself, I'd run the test in every mode the TV has and compare results because you know consumers aren't going to ignore additional modes.
I'm surprised this scam still works today. All of my cards automatically reject purchases where the shipping address isn't the billing address of my card. I can add addresses to the valid list, but I have to do it beforehand through their web site or through customer service. That should shut this kind of scam down.
Or the other obvious change of, instead of having the merchant charge my card, have me tell my bank/issuer to pay the merchant. Then the merchant never needs to know my card number and it's a lot harder for scam artists to operate.
How about an ad blocker that charges advertisers per view to let their ads be seen, and pays users a portion of that (say split it 10% to the blocker's developer, half the remainder to the site and half to the user) if they allow the ads to be shown to them. If the advertiser wants more views, they can either a) make more interesting ads that people actually want to see or b) offer more money for people's attention.
Can you afford to walk away from your job right this minute? Knowing you'll get no unemployment compensation, no welfare, no assistance of any kind? It's one thing to voluntarily follow orders, quite another when the person giving the orders is holding the welfare of your family hostage against your good behavior. In my book people who refuse to recognize this are complicit with management in the act, they directly help management perpetuate the conditions that let management get away with these crimes.
Exactly. The basic problem is a lack of management ethics. Management considers it perfectly acceptable to cheat like this, knowing they're cheating and breaking the law while doing so, and they expect everyone in the organization to follow along. Management also considers it perfectly acceptable to lie about why they let someone go, rather than simply fire them for disobeying orders (which would leave the employee free to say exactly what orders they disobeyed) they find some other innocuous excuse and leave the employee no real way to respond when asked by a future employer why they were terminated. Until management ethics is fixed, it won't be possible to do anything about engineering ethics.
I'd go limp: "We'll comply with your request. Please send us the contact information for the service that you'll accept as authoritative for whether or not a request from a particular IP address originates in France or not. We'll also require a binding agreement that the determination of this service cannot be contested by either Google or the French government, and that if any third party demonstrates that the service made an incorrect determination use of that service will be discontinued and the French government shall not demand compliance from Google until the French government has selected a new authority. Until we are in receipt of this information and agreement, Google will unfortunately be unable to operate the French-localized Google site and will be unable to serve search results for France or any French entity or person. Have a nice day.".
First rule: have facilities capable of running your business in more than one location. Everywhere is susceptible to disaster of one sort or another, but if you pick areas far apart that aren't geographically similar they probably won't both suffer disasters at the same time.
Second rule: the probability of disaster taking out your main facilities is 100%. It will happen. The only question is exactly when it'll happen, and the only constant in the answer is that it won't be at a good time. If anyone in your organization doesn't like this, remind them that reality doesn't really care what they like.
I think there'll still be apps, but things will evolve to having apps in parallel with APIs. For example, for an appointment-management service there'll be an app (or more than one, eg. a webapp for desktop use and a mobile app or mobile-optimized webapp for phone/tablet use) for customers who just want to let clients make appointments and want to be able to manage those appointments and don't need a lot of customization. There'll also be API access that would let customers get at the basic operations (with appropriate authentication and filtering for safety) that the apps themselves use so more sophisticated customers can use the service's functionality through a custom interface. It won't be an exclusive-or situation either, a customer may have their Web developer use the API to integrate setting up appointments into their own client web site while their staff use the standard webapp to manage appointments.
Neither the app nor the API will likely be free, either. The customer's clients won't pay in the above scenario, but aside from a trial period the customer would have to pay for access to the service (the amount probably depending on their usage and what features they want access to). We're about to hit a point where merely being able to get a huge userbase won't be considered valuable, you'll need to have a feasible roadmap for getting a revenue stream from your users. A thousand users each paying a monthly subscription will be more valuable than a million users not paying you anything. And frankly it's a lot easier to maintain paying users if you start them out as paying users.
It's complete bullshit, at least at the current state of the art. It's not a new idea either. People who aren't actual developers have been pushing this idea of drag-and-drop "programming" since the early 80s at least. 30 years of work, and the most they've managed are tools to automate generating the boilerplate code to lay out UI elements in the software's interface. They haven't even managed to automate moving the values from the UI fields into the software's internal objects/variables, the task's just too complex for their tools. So, why would anyone thing they'll overnight overcome all the problems and hurdles in their way and suddenly make orders of magnitude more progress in the next couple-three years than they have in the last 3 decades?
Well, #1 and #3 come under technical "Can we do it?", at least the parts where the company has the technical ability to switch providers if one goes out of business and to handle connectivity problems (I classify a provider going out of business as just a particularly severe and long-term connectivity problem, communications with their systems is completely down and won't ever be back up). The rest is all business decisions, the same sort business makes about every external vendor the company does business with. Legal issues in particular aren't something IT should be involved in, the company pays real lawyers to advise the business on that sort of thing and if I as a techie know more about the legal aspects than the lawyers something is really wrong.
The first call comes from the technical people, and answers the question "Is the company technically able to move to the cloud, and if not what's required to get it to that point?". Once you've got that covered, then business can decide whether it makes sense to move and whether they want to invest what it'll take to make it happen. If it isn't technically possible it doesn't matter how much business wants it, and business can't make a determination about investing what's needed to make it possible if they don't know how much investment it'll take. You can't make a cost/benefit decision if you don't know the cost.
The problem isn't the systems. It's 50 years of business logic embedded in the code that runs those systems. Half of it was never documented, because management needed it Right Now and once it was working they needed the developers on another project they also needed Right Now. Of the half that is documented, most of it has undocumented special cases in it and nobody has a clue whether they're needed anymore or not. And this is where the sticking point is, because you can't configure a canned solution to do the job if you don't know what the job is and there's always parts of it so arcane that the canned solutions just won't handle it (this is usually the final nail in the coffin of SAP projects that actually went long enough to get the basics working).
So the decision's more often whether to spend a million dollars on a new system and keep 100 developers, analysts and the like at $100K/year working for 8-10 years on the new system and keep those 10 COBOL developers working for the same period (because you need the old system working until the new one's at least mostly ready), or just keep the 10 COBOL developers working.
And some of those will be the governments of Western democracies. That's the truly maddening part.
The basic flaw is worse. They didn't just run one test, find the results they wanted and go with it. They ran a test with only an idea of what they wanted, then took all the results they got and picked out ones that were positive for conditions or treatments they could go with. It's like going into a test for a drug to treat heart attacks, finding that it doesn't do anything for heart attacks but does seem to lower cholesterol levels, and announcing that the trials of your new cholesterol medication were positive.
Having to declare up front what their goals are destroys the ability to cherry-pick like this. What we're seeing with the drop in positive results isn't so much the difference in clinical effectiveness of the drugs but the dragging into the spotlight of the pharma companies' ability to predict what their drugs will do and how well they'll do them. There's a very interesting blog here that covers a lot of this, and one conclusion that keeps coming up again and again is that medical biochemists and researchers don't really have a good way of predicting from lab results what a compound will do in a live human. It also highlights fairly often how the drug companies will keep pushing a drug through trials even though the results aren't encouraging. It's a common attitude in business and finance, that now that you've invested this much money in something you have to get some return out of it to justify the cost. It's also a common failing in gambling, the belief that now that you're in the hole you have to dig yourself out somehow. But in gambling, if you're holding a bad hand your best bet is to fold. Don't worry about how much you've already got in the pot, it's already lost. Fold and cut your losses before you throw any more money away. Drug companies are notoriously bad at making that decision to walk away. They're also notoriously bad at dealing with a field where there aren't many good rules you can follow to get results. MBAs like process and procedure and predictable results, and right now biochemical research is in a situation where the new stuff is all likely out in areas where there isn't a lot of research, there isn't a good map of the territory and you're going to be doing a lot of "poke it with a pointy stick and let's see what it does" work.
His class is focused on HTML/CSS/JS/etc. which means it's not Web design. Design is artwork and layout, for which yes PS is one of the standard tools (and maybe not the best one if, for instance, you're doing Material design for Android access or responsive design where fixed layouts to fit artwork are a no-no). But Web development, using HTML/CSS/JS/etc. to build the mechanics of the site and make it work, generally doesn't require any particular set of tools. In fact Photoshop's a bad fit here because the file formats you're going to need (mostly PNG, especially if you're going to do any sort of transparency) aren't it's native formats and it doesn't really "get" the more exotic technical tricks you'll need the way say the GIMP does.
Do you actually need all the metadata, layers and such in the PSD, or just the image data? If it's just the image data, have the art creators export the relevant parts as PNG or something (not JPEG for gods' sake) and work with that. Or the GIMP will read PSD files up to a point, usually well enough to get the image data, it's only the very complex PSD files that give it fits. If the art people complain, note that just as it's not their job to know the intricacies of HTML5 and CSS and Javascript needed to make a web site work it's similarly not the web mooks' jobs to know the intricacies of Photoshop and "Export as"/"Save as" shouldn't present that many problems.
If you do need layers and such as an integral part of the template, maybe what you need to do is separate the template extraction part of the process. Have a few machines with Photoshop, and the first step is to take the template to those machines and pull it apart to get the imagery needed plus the additional information like gradients and transparency and z-axis position converted from information in the PSD to the numeric values needed for CSS. Then take the results to the Linux systems to do the core work of assembling the web site.
The situation seems ripe for him to file a DMCA notice against all of Columbia's official film sites and materials. He can prove his film existed before Columbia's was even started, and he has Columbia's admission (in their DMCA notice against his work) that their work is similar enough to his for infringement to occur.
Even for a 40+-year-old male offices are too cold most of the time. And in southern Arizona the settings meant you hit a literally 40F+ wall walking out the building door. That isn't healthy. Although if you have to err it's better to have it set on the cool side, people can always add a sweater to stay warmer but you usually can't legally take clothing off if it's too warm.
Well, it'll solve the problem of the system eating them alive in terms of maintenance and support. Now it'll be eating them alive in terms of development costs instead.
No, wait, they'll need to keep the legacy systems running until the new ones are running, so it'll still be eating them alive in terms of maintenance and support too.
Amusingly most home routers already support most of that. #8 isn't feasible, a router doesn't have enough of a view into the traffic to do that kind of thing in real-time. And IMO #9 is better done on the printers. My laser printer's got Ethernet and a built-in print server (actually several, for the different protocols used by different operating systems). The rest is already a standard part of the firmware most router vendors base their own on. It's just that the vendors have disabled/removed a lot of the useful bits, or at least removed any access to them in their UI. Reflash your router with stock DD-WRT and you get pretty much everything you're asking for. Even the firewall. Every device on your network may have a public IPv6 address, but that doesn't mean the firewall will let inbound traffic through to them. The stock settings on mine are to allow established/related traffic through inbound, allow DHCPv6 traffic in to the router only, allow ICMPv6 traffic, and drop everything else. The IPv6 side follows the same rules as the IPv4 side: I can connect out, but nobody else can initiate a connection in. Oh, and for #5 I wouldn't build a big switch in, you aren't going to be rate-limited by the bandwidth to the router so use one LAN port to feed a larger switch that your network hangs off of. That also removes intra-LAN traffic from the router's switch.
Supporting multiple ISPs is an intricate bit of work, but it's mostly an extension of what's done to support the current WAN port. The biggest problem is that with 2 WAN connections you need a routing daemon and it's configuration has to be coordinated with both ISPs and that's going to be a nightmare.
If you don't care about keeping power consumption to a minimum, there's a lot of fun you can have with a mini-ITX or smaller board, a managed switch and an x86_64 build of DD-WRT.
That was by design. Leaving 64 bits for the host address lets them use the Ethernet MAC address (the most common hardware address) as the host address, which leaves only the local network prefix needed to complete configuring the interface and that can be gotten via the Router Advertisement protocol on the known link-local network (fe80::/10). And let's see. The public unicast allocation's 2000::/3, with a few exception blocks carved out for things like 6to4 and Teredo. That's roughly 60 bits for the unique network number, or not quite 268.5 thousand 4-billion+ blocks of network addresses. 0000::/3 and e000::/3 are already in use, but that still leaves us with 5 more /3 blocks we can assign for unicast use without conflicting with anything if the 2000::/3 block runs out. So I think that even with some inefficiency that'll hold us for a good while.
So, precisely how again do they suggest sites verify ages? It needs to at least be proof against a minor with an adult's "borrowed" credit card, and it can't require sites to violate the law. This isn't a technical problem here, it's completely independent of the technology. If these politicians want the problem solved, they need to spend some time thinking about how to solve the problem. And yes, "make someone else solve it" is a valid option but only if having the sites apply that solution by making the politicians the "someone else" is also a valid option.
Yeah, I'm thinking of the change from the Win95 Start menu to the Win7 one. Program Manager, however, acted pretty much as the Start button, you opened it and then navigated folders fairly logically (you wanted an application, you opened the Applications folder and looked there). The applications you used all the time you copied to the desktop so you'd have them at your fingertips. Which, I've noticed, is still how people handle common applications, with "copy it to the taskbar" a close second and the two "pin" options vying for a distant third.
And it still remains: even secretaries had no problem grokking how to work Win3.1's desktop and programs.
The total change from the Windows 3.1 Start button to the subsequent Start buttons was making the Start menu a 2-column menu, putting the contents of the former Programs menu in the left pane and putting the rest of the Start menu items in the right pane. That's it. Oh, and making the initial view not show all the Programs items but only a subset, with an extra item at the bottom to show everything in the same form as it was under the Programs menu.
As for Win3.1 being complicated, every secretary I knew managed to get a handle on it within a few days so it couldn't have been that complicated. The only people I know of who couldn't figure out Win3.1 are the ones who to this day need repeated reminders of how to get to anything that's not directly on their desktop, so methinks the problem doesn't lie in Windows.