While some grocery chains like Safeway do delivery, they're not very good at it. They're picking from store shelves. So they don't know, when the order is taken, if the item is in stock. Safeway tends to deliver with some items missing. Automated warehousing operations know what they have in stock when the system takes the order.
If that's the level of service that they're providing, the world will be a better place when they're out-competed. Sucks if you're a Safeway employee, but reduces the level of suck for many other people so it's a net gain. That's the reality of a proper free market. (And having shopped at Safeway in the US, the sooner they get replaced, the better IMO. Horrible place.)
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
The problem is that customers are not nearly as available as people would like. Either they're located offsite (and won't relocate to be with you or allocate space for you to be with them), or they're short of time because of their other commitments, or they the kind of people who hate being shown works-in-progress.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
XML doesn't magically solve everything in this regard.
There are no silver bullets at all in this area. You can make the container format self-describing, and the tree structure self-describing (which is pretty much what XML gives you), but the hard problem of capturing the actual semantic meanings of the nodes in the tree is just going to remain that. You could attach "semantic meaning descriptors" of course, but whose to say that they're going to be understandable by anyone? (Indeed, where I've seen such things they've typically been less understandable than the original non-semantic nodes and have depended on comprehending a large body of complex documents on the open internet at the same time, which is a total failure mode on many levels.)
But going for XML (or ASN.1 or JSON or YAML or any number of other tree description schemes) is still better than trying to also pick apart the mess from horrible custom binary dump. It's at least one less obstacle, as you at least can read what the original generator thought it was sensible to tag the tree as. (Other layers of encoding that are reasonably standardized and so don't add to the problem are using a defined character encoding such as UTF-8 or ASCII, and using a compressed packaging format like ZIP or gzip.)
Both have published specifications, so reverse engineering shouldn't be necessary. However, Microsoft's XML includes things that are not defined in the specification. That was one of the objections to giving it status as an open standard.
Vendor extensions are sometimes a necessary evil, but just how much you object to them depends on how much they impact on the comprehensibility of the document by tools other than the ones by the original vendor. Are they generating those in newly-created documents or are they just there in documents converted from a previous format? The latter, while not nice, would be not a great problem as it would be possible to get them documented as vendor extensions for legacy support (even if it was "guerilla documentation" and not official), but if critical new/current features require lots of vendor extensions then that's highly problematic.
If a tool can read in the document, throw away all the vendor extensions, and still completely understand the document, those extensions cannot be deeply objectionable. (Very few people get worked up about one-pixel layout tweaks, but putting the actual content inside an extension isn't good at all.)
The other classic reason REST fails is constraining verbs to the use of available HTTP verbs... No really WTF? This is wholly insufficient to address anything but non trivial 'CRUD' use and does not lend itself to any meaningful level of reuse as definitions are streched to encapsulate a handful of static verbs...so normally someone will just add a modifier to a URL to bypass the whole issue.
Just define your own HTTP verbs and use those as well. As long as you support the standard OPTIONS request, it should all be "REST" enough.
Or just pack everything over POST and party like it's SOAP once again!
Granted, Teslas won't be charging up on power generated in China, but their Panasonic batteries (and many if not most car parts) are made there.
You've got to factor in both local and global pollution, and they're often driven by very different factors.
Local pollution is driven by things like particulate emissions, particularly soot and sulfur dioxide. It's a real pressing problem in many parts of the world, and actions that reduce it are a good idea. What's more, it's something that people mostly know how to deal with through appropriate regulation (though they sometimes don't, for a whole bunch of reasons). Global pollution is driven much more by overall energy consumption, carbon dioxide emissions, high-altitude sulfates, that sort of thing. It tends to be far less immediately visible to people, and more likely to affect someone else to a proportionately greater extent than local pollution, so getting it regulated is much more difficult.
Both types of pollution need to be tackled. Really. We can't just think about one of them. The plus side of an electric vehicle is that it doesn't require carbon-derived power at all: there are other energy sources that it can ultimately use, and that can greatly reduce the amount of pollution produced. The downside is that the batteries are made of comparatively exotic materials, which are much more likely to be associated with a high pollution load at the point where they are produced. (OTOH, that's mostly local pollution and you can reduce the pollution costs associated with fuel extraction. Tricky to work out the exact net effect.)
The proper measure here is the specific energy - that is, by weight, not by volume.
Actually, that's not entirely useful either. What really matters is how much usable stored energy can we put on board a vehicle of reasonable size, and how available the particular energy source is. You have a free choice of storage mechanism, but not a free choice of overall total volume or mass, where those include both the on-vehicle storage system and the engine.
I think we can all agree that the maximum energy storage is done using antimatter, but that's not practical due to the mass of the containment system, the high-energy radiation from the engine, or the cost of obtaining it. (I can't believe I just wrote an outline analysis of using antimatter to power cars...)
As others have noted, Wikipedia is pretty much the only website that has even implemented src-set. This is not a big problem.
There are quite a few sites that use MediaWiki (often with heavy skinning) and many of those will be sites that users are more likely to visit than average. On the other hand, the number of those that use a srcset is probably quite a bit lower (unless MediaWiki is doing the work behind the scenes). In short, while the problem isn't pressing, it should be addressed sooner rather than later as it is likely to become more prevalent.
Mind you, I think there are good reasons for just scrapping srcset entirely; the current draft spec states that
"This, unfortunately, can be used to perform a rudimentary port scan of the user's local network (especially in conjunction with scripting, though scripting isn't actually necessary to carry out such an attack). User agents may implement cross-origin access control policies that are stricter than those described above to mitigate this attack, but unfortunately such policies are typically not compatible with existing Web content."
Good reason for just throwing it away and trying something else less security-stupid, IMO.
They should be able to become aware if they choose to. Forcing everyone to be aware of everything is just not going to fly. Not everyone wants to read and write code. Not everyone wants to do heart surgery. Not everyone wants to recycle old batteries. Specialization means that there's time to actually become good at doing something.
Then you can clearly explain why there should not be a standard way to manage the discovery of media type variants handled and to allow the codec and the service provider to communicate securely. While I would agree that there should not be a particular type of DRM-enabled codec mandated, there ought at least to be an official mechanism for the presence of optional software plugin modules capable of doing a particular task (e.g., video playback) and to determine that of the ones that are available, all, some or none of them support DRM that is compatible with what the service provider can provide.
Don't mandate that Netflix works. Mandate enough that they can definitively discover that things won't work under the conditions they are willing to tolerate.
If you read about it, it sounds delicious. Once you actually find out how it's made, you might change your mind. And you have to find out how it's made if you actually want to do anything useful with it.
It's also capable of being seriously mind-bending when it screws something up. (Today, we found the weirdest of problems with encoding handling in templates. On one level I can see what exactly happened and how it came to pass, but on another level WHY, OH GREAT FLYING SPAGHETTI MONSTER? WHY?)
The fact is that nobody... I mean *nobody* needs one more obscure little language whose wondrous new features would just be another add-in library in C++.
Some programming languages have been sold into strict C-only shops on the basis that the implementation is just a "C library" and the script files were just "soft configuration definitions". You know that's silly, and I know that's silly, but it's happened for sure. (Also, being a nice add-in library can be a nice ambition: that's a real niche, even if an occupied one.)
You're right that the USP is unclear though. Why would anyone bother with it as opposed to the plethora of other very similar languages that exist and have existing user communities?
my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function
Not true, since the type of a reference is introspectable and the errors that are thrown can be trapped. It's up to the compiler to prove that it can omit the checks on a reference; a good reason for omitting a check would be when you know for sure that the check has already been done earlier in the function.
If mere 350 miles suck for you, you are doing something wrong.
Driving in a part of the world with a high traffic density is "doing something wrong"? There's a world of difference between driving on a nice open road with only a rare other vehicle (very pleasant, actually) and slogging through heavy traffic (sucks a lot because you have to pay close attention the whole damn time) but for some people, the place where they're starting from and the place where they're going are just plain separated by big cities with choked roads.
350 miles in heavy traffic? Flying is better, as is taking a train, but might not be more economic (depends on how many people are going in the group).
They've still got to be powered, and I'm not at all convinced that solar would do it without costing far more than a cable run. Railway operators know all about running cables.
That said, I suspect that advantage of a drone is that it allows you to use an expensive setup and move it to somewhere else easily once you've dealt with the problem in one location. Putting in lots of fixed hardware by contrast requires a lot more investment in the construction work to deal with a problem that stops (at least for a while) once you've caught the miscreants.
Both Obama and Bush are far better than the Tudors or the Stuarts. The Stuarts were such rights-trampling pricks that they started a civil war several times — even if not all of those are outright titled that — and the Tudors took the broadest definition of treason possible (i.e., disagreeing with the king/queen was a capital offense). Can you imagine just how either of those would play in the modern world?
Indeed, the Cheney laws are totally unthinkable in Germany or any other N/W European country.
The drilling and production of oil and gas is tightly regulated and monitored.
Another difference, at least between the US and the UK, is that subterranean resource ownership is decided in a totally different way, so people are a lot more positive about fracking in the US (as the real estate owners — the people with substantive interest — stand to gain financially).
Slashdot Mirror
While some grocery chains like Safeway do delivery, they're not very good at it. They're picking from store shelves. So they don't know, when the order is taken, if the item is in stock. Safeway tends to deliver with some items missing. Automated warehousing operations know what they have in stock when the system takes the order.
If that's the level of service that they're providing, the world will be a better place when they're out-competed. Sucks if you're a Safeway employee, but reduces the level of suck for many other people so it's a net gain. That's the reality of a proper free market. (And having shopped at Safeway in the US, the sooner they get replaced, the better IMO. Horrible place.)
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
The problem is that customers are not nearly as available as people would like. Either they're located offsite (and won't relocate to be with you or allocate space for you to be with them), or they're short of time because of their other commitments, or they the kind of people who hate being shown works-in-progress.
Also, customers aren't (necessarily) users or vice versa. That's a major piece of tension right there.
XML doesn't magically solve everything in this regard.
There are no silver bullets at all in this area. You can make the container format self-describing, and the tree structure self-describing (which is pretty much what XML gives you), but the hard problem of capturing the actual semantic meanings of the nodes in the tree is just going to remain that. You could attach "semantic meaning descriptors" of course, but whose to say that they're going to be understandable by anyone? (Indeed, where I've seen such things they've typically been less understandable than the original non-semantic nodes and have depended on comprehending a large body of complex documents on the open internet at the same time, which is a total failure mode on many levels.)
But going for XML (or ASN.1 or JSON or YAML or any number of other tree description schemes) is still better than trying to also pick apart the mess from horrible custom binary dump. It's at least one less obstacle, as you at least can read what the original generator thought it was sensible to tag the tree as. (Other layers of encoding that are reasonably standardized and so don't add to the problem are using a defined character encoding such as UTF-8 or ASCII, and using a compressed packaging format like ZIP or gzip.)
Both have published specifications, so reverse engineering shouldn't be necessary. However, Microsoft's XML includes things that are not defined in the specification. That was one of the objections to giving it status as an open standard.
Vendor extensions are sometimes a necessary evil, but just how much you object to them depends on how much they impact on the comprehensibility of the document by tools other than the ones by the original vendor. Are they generating those in newly-created documents or are they just there in documents converted from a previous format? The latter, while not nice, would be not a great problem as it would be possible to get them documented as vendor extensions for legacy support (even if it was "guerilla documentation" and not official), but if critical new/current features require lots of vendor extensions then that's highly problematic.
If a tool can read in the document, throw away all the vendor extensions, and still completely understand the document, those extensions cannot be deeply objectionable. (Very few people get worked up about one-pixel layout tweaks, but putting the actual content inside an extension isn't good at all.)
Steradians. We're mapping in 3D, bitches!
The other classic reason REST fails is constraining verbs to the use of available HTTP verbs... No really WTF? This is wholly insufficient to address anything but non trivial 'CRUD' use and does not lend itself to any meaningful level of reuse as definitions are streched to encapsulate a handful of static verbs...so normally someone will just add a modifier to a URL to bypass the whole issue.
Just define your own HTTP verbs and use those as well. As long as you support the standard OPTIONS request, it should all be "REST" enough.
Or just pack everything over POST and party like it's SOAP once again!
The issue tracking system is a bit more critical
They should put each project's issues in a git repository, so that you can trivially keep them replicated on your own systems.
Granted, Teslas won't be charging up on power generated in China, but their Panasonic batteries (and many if not most car parts) are made there.
You've got to factor in both local and global pollution, and they're often driven by very different factors.
Local pollution is driven by things like particulate emissions, particularly soot and sulfur dioxide. It's a real pressing problem in many parts of the world, and actions that reduce it are a good idea. What's more, it's something that people mostly know how to deal with through appropriate regulation (though they sometimes don't, for a whole bunch of reasons). Global pollution is driven much more by overall energy consumption, carbon dioxide emissions, high-altitude sulfates, that sort of thing. It tends to be far less immediately visible to people, and more likely to affect someone else to a proportionately greater extent than local pollution, so getting it regulated is much more difficult.
Both types of pollution need to be tackled. Really. We can't just think about one of them. The plus side of an electric vehicle is that it doesn't require carbon-derived power at all: there are other energy sources that it can ultimately use, and that can greatly reduce the amount of pollution produced. The downside is that the batteries are made of comparatively exotic materials, which are much more likely to be associated with a high pollution load at the point where they are produced. (OTOH, that's mostly local pollution and you can reduce the pollution costs associated with fuel extraction. Tricky to work out the exact net effect.)
The proper measure here is the specific energy - that is, by weight, not by volume.
Actually, that's not entirely useful either. What really matters is how much usable stored energy can we put on board a vehicle of reasonable size, and how available the particular energy source is. You have a free choice of storage mechanism, but not a free choice of overall total volume or mass, where those include both the on-vehicle storage system and the engine.
I think we can all agree that the maximum energy storage is done using antimatter, but that's not practical due to the mass of the containment system, the high-energy radiation from the engine, or the cost of obtaining it. (I can't believe I just wrote an outline analysis of using antimatter to power cars...)
As others have noted, Wikipedia is pretty much the only website that has even implemented src-set. This is not a big problem.
There are quite a few sites that use MediaWiki (often with heavy skinning) and many of those will be sites that users are more likely to visit than average. On the other hand, the number of those that use a srcset is probably quite a bit lower (unless MediaWiki is doing the work behind the scenes). In short, while the problem isn't pressing, it should be addressed sooner rather than later as it is likely to become more prevalent.
Mind you, I think there are good reasons for just scrapping srcset entirely; the current draft spec states that
Good reason for just throwing it away and trying something else less security-stupid, IMO.
Users should be aware of what's going on.
They should be able to become aware if they choose to. Forcing everyone to be aware of everything is just not going to fly. Not everyone wants to read and write code. Not everyone wants to do heart surgery. Not everyone wants to recycle old batteries. Specialization means that there's time to actually become good at doing something.
I am confident that DRM should not be a standard
Then you can clearly explain why there should not be a standard way to manage the discovery of media type variants handled and to allow the codec and the service provider to communicate securely. While I would agree that there should not be a particular type of DRM-enabled codec mandated, there ought at least to be an official mechanism for the presence of optional software plugin modules capable of doing a particular task (e.g., video playback) and to determine that of the ones that are available, all, some or none of them support DRM that is compatible with what the service provider can provide.
Don't mandate that Netflix works. Mandate enough that they can definitively discover that things won't work under the conditions they are willing to tolerate.
A proxy never works for HTTPS
Yes it does, but only if the proxy supports CONNECT properly.
The technically adept people (read R&D dept) are the bane of our existence, as they constantly need changes made / make changes without consulting us.
Only because you insist on having control.
If you read about it, it sounds delicious. Once you actually find out how it's made, you might change your mind. And you have to find out how it's made if you actually want to do anything useful with it.
It's also capable of being seriously mind-bending when it screws something up. (Today, we found the weirdest of problems with encoding handling in templates. On one level I can see what exactly happened and how it came to pass, but on another level WHY, OH GREAT FLYING SPAGHETTI MONSTER? WHY?)
Time to move on then. You can't let those cargo-cult following "cool kids" catch up...
the dam song(s)
What?
"I'm big and wooden, yo ho ho,
Made by beavers, in the snow,
I hold back water, now you know,
I'm a happy dam, restraining the flow!"
Not quite a top ten hit I think...
The fact is that nobody... I mean *nobody* needs one more obscure little language whose wondrous new features would just be another add-in library in C++.
Some programming languages have been sold into strict C-only shops on the basis that the implementation is just a "C library" and the script files were just "soft configuration definitions". You know that's silly, and I know that's silly, but it's happened for sure. (Also, being a nice add-in library can be a nice ambition: that's a real niche, even if an occupied one.)
You're right that the USP is unclear though. Why would anyone bother with it as opposed to the plethora of other very similar languages that exist and have existing user communities?
Ok, it's what good comments are for.
The GP's comment is a good comment; it proves for sure that a moron has been loose on the code in the past.
my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function
Not true, since the type of a reference is introspectable and the errors that are thrown can be trapped. It's up to the compiler to prove that it can omit the checks on a reference; a good reason for omitting a check would be when you know for sure that the check has already been done earlier in the function.
If mere 350 miles suck for you, you are doing something wrong.
Driving in a part of the world with a high traffic density is "doing something wrong"? There's a world of difference between driving on a nice open road with only a rare other vehicle (very pleasant, actually) and slogging through heavy traffic (sucks a lot because you have to pay close attention the whole damn time) but for some people, the place where they're starting from and the place where they're going are just plain separated by big cities with choked roads.
350 miles in heavy traffic? Flying is better, as is taking a train, but might not be more economic (depends on how many people are going in the group).
Cable? No WIFI in your world?
They've still got to be powered, and I'm not at all convinced that solar would do it without costing far more than a cable run. Railway operators know all about running cables.
That said, I suspect that advantage of a drone is that it allows you to use an expensive setup and move it to somewhere else easily once you've dealt with the problem in one location. Putting in lots of fixed hardware by contrast requires a lot more investment in the construction work to deal with a problem that stops (at least for a while) once you've caught the miscreants.
Like Obama after the Bushes?
Both Obama and Bush are far better than the Tudors or the Stuarts. The Stuarts were such rights-trampling pricks that they started a civil war several times — even if not all of those are outright titled that — and the Tudors took the broadest definition of treason possible (i.e., disagreeing with the king/queen was a capital offense). Can you imagine just how either of those would play in the modern world?
That the basement is full of water just means that it is perfect for parking your secret fleet of nuclear mini-submarines.
Indeed, the Cheney laws are totally unthinkable in Germany or any other N/W European country.
The drilling and production of oil and gas is tightly regulated and monitored.
Another difference, at least between the US and the UK, is that subterranean resource ownership is decided in a totally different way, so people are a lot more positive about fracking in the US (as the real estate owners — the people with substantive interest — stand to gain financially).