No, it is the original product designers' fault for not making a freeze-proof product. It's not milk, you know, it the U.S. climate it is likely to freeze at various points during distribution. That stuff is usually shipped in unheated trailers.
Now that's just creepy. A friend owns a local non-franchise drive-through joint and I've helped them implement just that, with a license plate reader looking precisely at what would pass for turn lanes. The length of the drive-through queue is monitored through another camera, and the license plates of cars entering the drive-through lane are read at two locations too. All of the processing is done without human intervention - nobody needs to look at those camera feeds, other than to feel good and for service/troubleshooting.
After an initial 3 month period of gathering statistics, it operated for another 2 months silently generating order data that was compared with orders entered by cashiers. After this dry run, it was turned on and does in fact generate orders on the fly. It has had some truly remarkable outcomes. During rush periods, most clientele is so predictable, that the average throughput is up 2x even when no-one is trying very hard. When a customer starts the order, the cashier's screen is already pre-populated with the expected items, in fact, and the items are marked with predicted likelihoods of being correct (it's a simple 4-level bar). Items with 4-bar-green status are likely already being prepared at that time.
Some customers, I swear, just don't exactly remember the exact options they order each time:)
Another thing that we added later was pre-swipe for the payment, so that at the time of receiving the food you don't have to waste time dealing with the credit card. The car at the pre-swipe location has the plate read, and it's compared to the plate read at the window location, so that even if people decide to leave the drive through, as happens sometimes, nobodies' payment is in jeopardy. To preempt the PCI nuts: I do know what I'm doing, and the occasional Target-style breach just makes me chuckle.
Because, obviously, Staples special-orders print cartridges with an extra sprinkling of magic pixie dust in the ink. When you return the ones without pixie dust in them, you obviously defraud Staples. Makes sense to me, duh.
Even the original 8086 had an instruction cache (called a prefetch buffer IIRC). Most contemporary cache-less pipelined micro controllers also do an equivalent of prefetch.
Would an on die cache tell the CPU it fetched some predictive instructions that it doesn't need but might like?
Seriously? In a word: YES! CPUs have been doing predictive prefetch for quite a while. Speculative execution is a generalization of this: the prefetched stuff is not inputs to the computation, but outputs of it. Also widely implemented.
This is very informative, you only forgot the most important keyword: It's called prefetch. When something has its own word to describe it, we know it's really a common thing.
Use of a variable-length encoding for internal storage in a string type is really introducing a lot of runtime inefficiency, so it's best avoided. IMHO it was a valid tradeoff between flexibility and performance to use UCS-2 - a fixed-width encoding, as opposed to say UTF-16. It also reduces storage by 50% compared to using the fixed-width UTF-32, but makes some less-used code points non-representable.
There's nothing "emphasized" about latin1 in Qt, not even in Qt 4. These days you're supposed to encode your source code in UTF-8, and set this as the default encoding for 8-bit-to-QString roundtrips. I haven't used latin1 in Qt 4 code in a long while now.
Seems more like an understanding fail to me. Their business is not built on Google. It's built on a platform abstraction library that currently works for their intended uses. It's a closed book, they don't need any further involvement from Google. If they want to, they can fork it and maintain it themselves. They've already got a big trampoline so it'd still be less work to maintain that code than to come you with a yet another in-house, buggy, under-tested "framework".
Those "proper" APIs are usually chock full of bugs ("features"), intricacies, and generally can be a pain to work with. All this has been handled by people who develop the platform abstraction. You really need to go out more and look at how convoluted real-life cross-platform code is. All this crap took long time and lot of effort to get done. You can use it and get ahead, or you can reinvent the wheel, usually in a buggy way. Your choice.
You do know, you raving lunatic, that the fine article has got nothing, nothing at all to do with plugins, and nothing to do with NPAPI? Informative, my ass. Another fucking idiot. Why do people, who see "Chrome" and "API" in the same paragraph, automatically think it has got anything to do with web-browser-centric development? The whole point is that they are using the platform abstraction code, present in any large cross-platform software project. Firefox got it, Chrome got it, LibreOffice got it, many cross-platform application development frameworks have it. What's so hard to wrap your head around that?
You're just being obnoxious here. You seriously think that the stuff they're after is in the C++ standard library? Most of it, like 95% of it, isn't, and what is, is already used as-is by Chrome code.
There is a very efficient, hardware-assisted Java runtime available from Azul, but that pretty much just proves your point. You need dedicated hardware to make Java scream.
Modern C++, if you're not dumb about how you use it, lets you avoid all of the C's unsafety, automagically, and it can enforce many safety constraints for you at compile time, too. I don't really understand why anyone writing big, scalable server applications would want to use Java when running the same stuff on C++ will cost you less in datacenter power & cooling.
They had alternatives. For native C++ development, they could have used Chrome's platform abstraction, Mozilla's, Apache's, or Qt. I'd say that going with Chrome may be a bit against the grain, but hey, if it works for them, it works for them. I wonder how well the damn thing is documented, because it's hard to beat Qt's documentation.
Sure, but the standard C library has promoted a certain groupthink where you don't care about pesky details like buffer lengths. Sometimes an API can have negative didactic impacts. I think a successful API design is a mixture of software design and pedagogy - after all, APIs are very often used by people much less skilled than the library developers.
Not all of them are available to everyone - seriously, you talk like you do because you haven't actually checked it. Remember: details count, a casual look at things doesn't help here at all, only furthers your hopefully temporary delusion on that matter. None of the subject-to-GPL RPMs are available for RHEL without repercussions.
Doing things the old way without the readouts was co-adapted to how the machines were designed. You have a divider, it offers a fixed set of angles, and the designs are made to be machined with those dividers in mind. The axis cranks on the mills/lathes were labeled in a certain way, say with binary imperial fractions, and the designs were made to utilize that. And so on. Yes, I'm talking about quite old-style machines, probably last made half a century ago, but still. A modern CAD drawing would make a 1950's machinist go nuts with excitement: just look at how many extra hours I can bill for that!
The biggest thing I don't get: why the fuck don't they use the foreverlasting polyethylene piping like you see in Europe? The standard method of joining those PE pipes is thermal welding, essentially making the entire pipe system one contiguous piece of material. Why does anyone approve any steel or iron piping for intra-city gas distribution at all? It's nuts. You can have copper or iron piping inside of the buildings, for fire safety, if those pipes can be routed in non-condesing environment. That's about it. Iron pipes routinely rust on external threaded connections. Almost anywhere in the U.S. you go and see iron gas pipes exposed to the elements (like they always are around gas meters), it stinks due to leaking gas. Gas stink is everywhere in the U.S., it's like going full retard and being proud of it.
With a large enough power supply, you don't want electrolysis. You want CO2+H2O into methane and oxygen. With electrolysis, you still need chemical scrubbers for CO2 extraction, so you need power + source of replaceable scrubber material.
Slashdot Mirror
No, it is the original product designers' fault for not making a freeze-proof product. It's not milk, you know, it the U.S. climate it is likely to freeze at various points during distribution. That stuff is usually shipped in unheated trailers.
So, you seriously think they no internal measures of the item's popularity or niche-ness?
Now that's just creepy. A friend owns a local non-franchise drive-through joint and I've helped them implement just that, with a license plate reader looking precisely at what would pass for turn lanes. The length of the drive-through queue is monitored through another camera, and the license plates of cars entering the drive-through lane are read at two locations too. All of the processing is done without human intervention - nobody needs to look at those camera feeds, other than to feel good and for service/troubleshooting.
After an initial 3 month period of gathering statistics, it operated for another 2 months silently generating order data that was compared with orders entered by cashiers. After this dry run, it was turned on and does in fact generate orders on the fly. It has had some truly remarkable outcomes. During rush periods, most clientele is so predictable, that the average throughput is up 2x even when no-one is trying very hard. When a customer starts the order, the cashier's screen is already pre-populated with the expected items, in fact, and the items are marked with predicted likelihoods of being correct (it's a simple 4-level bar). Items with 4-bar-green status are likely already being prepared at that time.
Some customers, I swear, just don't exactly remember the exact options they order each time :)
Another thing that we added later was pre-swipe for the payment, so that at the time of receiving the food you don't have to waste time dealing with the credit card. The car at the pre-swipe location has the plate read, and it's compared to the plate read at the window location, so that even if people decide to leave the drive through, as happens sometimes, nobodies' payment is in jeopardy. To preempt the PCI nuts: I do know what I'm doing, and the occasional Target-style breach just makes me chuckle.
Yes - that's why oscillating bone saws work!
Because, obviously, Staples special-orders print cartridges with an extra sprinkling of magic pixie dust in the ink. When you return the ones without pixie dust in them, you obviously defraud Staples. Makes sense to me, duh.
How insensitively cloddish of them. My wife would love that thing in a gift wrap!
Even the original 8086 had an instruction cache (called a prefetch buffer IIRC). Most contemporary cache-less pipelined micro controllers also do an equivalent of prefetch.
Would an on die cache tell the CPU it fetched some predictive instructions that it doesn't need but might like?
Seriously? In a word: YES! CPUs have been doing predictive prefetch for quite a while. Speculative execution is a generalization of this: the prefetched stuff is not inputs to the computation, but outputs of it. Also widely implemented.
This is very informative, you only forgot the most important keyword: It's called prefetch. When something has its own word to describe it, we know it's really a common thing.
Nice, I forgot about that!
Use of a variable-length encoding for internal storage in a string type is really introducing a lot of runtime inefficiency, so it's best avoided. IMHO it was a valid tradeoff between flexibility and performance to use UCS-2 - a fixed-width encoding, as opposed to say UTF-16. It also reduces storage by 50% compared to using the fixed-width UTF-32, but makes some less-used code points non-representable.
There's nothing "emphasized" about latin1 in Qt, not even in Qt 4. These days you're supposed to encode your source code in UTF-8, and set this as the default encoding for 8-bit-to-QString roundtrips. I haven't used latin1 in Qt 4 code in a long while now.
No. And google doesn't really get any benefits from people reusing Chrome's portability layer. Their salespeople couldn't care less about this.
Exactly. Qt is an application development framework. Networking is done differently on every fucking platform.
Seems more like an understanding fail to me. Their business is not built on Google. It's built on a platform abstraction library that currently works for their intended uses. It's a closed book, they don't need any further involvement from Google. If they want to, they can fork it and maintain it themselves. They've already got a big trampoline so it'd still be less work to maintain that code than to come you with a yet another in-house, buggy, under-tested "framework".
Those "proper" APIs are usually chock full of bugs ("features"), intricacies, and generally can be a pain to work with. All this has been handled by people who develop the platform abstraction. You really need to go out more and look at how convoluted real-life cross-platform code is. All this crap took long time and lot of effort to get done. You can use it and get ahead, or you can reinvent the wheel, usually in a buggy way. Your choice.
You do know, you raving lunatic, that the fine article has got nothing, nothing at all to do with plugins, and nothing to do with NPAPI? Informative, my ass. Another fucking idiot. Why do people, who see "Chrome" and "API" in the same paragraph, automatically think it has got anything to do with web-browser-centric development? The whole point is that they are using the platform abstraction code, present in any large cross-platform software project. Firefox got it, Chrome got it, LibreOffice got it, many cross-platform application development frameworks have it. What's so hard to wrap your head around that?
This should be more like -5, Gone Full Retard.
You're just being obnoxious here. You seriously think that the stuff they're after is in the C++ standard library? Most of it, like 95% of it, isn't, and what is, is already used as-is by Chrome code.
There is a very efficient, hardware-assisted Java runtime available from Azul, but that pretty much just proves your point. You need dedicated hardware to make Java scream.
Modern C++, if you're not dumb about how you use it, lets you avoid all of the C's unsafety, automagically, and it can enforce many safety constraints for you at compile time, too. I don't really understand why anyone writing big, scalable server applications would want to use Java when running the same stuff on C++ will cost you less in datacenter power & cooling.
They had alternatives. For native C++ development, they could have used Chrome's platform abstraction, Mozilla's, Apache's, or Qt. I'd say that going with Chrome may be a bit against the grain, but hey, if it works for them, it works for them. I wonder how well the damn thing is documented, because it's hard to beat Qt's documentation.
Sure, but the standard C library has promoted a certain groupthink where you don't care about pesky details like buffer lengths. Sometimes an API can have negative didactic impacts. I think a successful API design is a mixture of software design and pedagogy - after all, APIs are very often used by people much less skilled than the library developers.
Not all of them are available to everyone - seriously, you talk like you do because you haven't actually checked it. Remember: details count, a casual look at things doesn't help here at all, only furthers your hopefully temporary delusion on that matter. None of the subject-to-GPL RPMs are available for RHEL without repercussions.
Doing things the old way without the readouts was co-adapted to how the machines were designed. You have a divider, it offers a fixed set of angles, and the designs are made to be machined with those dividers in mind. The axis cranks on the mills/lathes were labeled in a certain way, say with binary imperial fractions, and the designs were made to utilize that. And so on. Yes, I'm talking about quite old-style machines, probably last made half a century ago, but still. A modern CAD drawing would make a 1950's machinist go nuts with excitement: just look at how many extra hours I can bill for that!
The biggest thing I don't get: why the fuck don't they use the foreverlasting polyethylene piping like you see in Europe? The standard method of joining those PE pipes is thermal welding, essentially making the entire pipe system one contiguous piece of material. Why does anyone approve any steel or iron piping for intra-city gas distribution at all? It's nuts. You can have copper or iron piping inside of the buildings, for fire safety, if those pipes can be routed in non-condesing environment. That's about it. Iron pipes routinely rust on external threaded connections. Almost anywhere in the U.S. you go and see iron gas pipes exposed to the elements (like they always are around gas meters), it stinks due to leaking gas. Gas stink is everywhere in the U.S., it's like going full retard and being proud of it.
With a large enough power supply, you don't want electrolysis. You want CO2+H2O into methane and oxygen. With electrolysis, you still need chemical scrubbers for CO2 extraction, so you need power + source of replaceable scrubber material.