A lot of former Self and StrongTalk people went to work on v8 (and later Dart and WebAssembly) at Google. If you look at Dart, you can see that it's very much StrongTalk-with-braces. If you look at the name of the project lead, you'll understand why.
The 'secure enclave' scheme is 100% pure 'security through obscurity'.
Nonsense. The secure enclave is a separate ARM core that has its own private memory and is designed so that you can write keys to it and it will do signing and encryption / decryption on your behalf, but you can't exfiltrate the keys. A similar design appears in a few Android devices, but the lack of uniformity means that most software doesn't make good use of it. There are valid criticisms of iOS device security, but this one just makes you look like an idiot.
Apparently it's not dead, but for those of us for whom this is the first time that we've heard it (other than as the first version of Android, which, thankfully, is dead), what is it?
this same thing happens naturally as well, the price of the ads being determined by the value they give for the advertisers, the ads will just be cheaper to run per click in the same proportion there are fake clicks. it doesn't solve the problem that people are stupid enough to sign up to something, install something or to buy something advertised in such a way.
The flaw in your logic is that advertising space is limited. Remember those late '90s pages that were 90% banner ads? There's a reason that they died. Price per click goes down, but only towards a minimum generated by the fact that companies are bidding for the same space. The goal is to make the cost of online advertising higher than the value of online advertising (various analysts believe that it's very close to that point now).
Probably. Both, at launch, looked pretty much like an updated PalmOS and fairly similar to Symbian Series 60. Most of the common UI elements between iOS and Android were found in at least one, if not both, of those prior smartphone operating systems.
I didn't, but I'm not surprised. Last time I spoke to someone at Oracle, they said that the revenue from the DB was up, but they had very few new customers. Their real problem is Moore's law and friends. In the early '90s, payroll for a moderately large company took a serious database on high-end hardware to manage, with several hours of compute time to complete the payroll calculations each week. Now, that same company is maybe 10 times the size, but you can buy a computer more than 100 times better in terms of RAM, storage capacity, storage speed, and processor speed, for a few hundred dollars. On a modern machine, you don't need carefully optimised queries and carefully designed on-disk data structures - you can probably fit the whole thing in RAM and run the computations in Lua and still get the whole thing done in a second or two. At one end of the market, most customers can now run their systems with cheap commodity hardware and software. At the other end of the market, companies like Facebook and Google have more data than Oracle can easily handle and couldn't afford Oracle license fees even if there was a viable Oracle product for them to buy. The middle is gradually shrinking.
I was going to reply saying that macOS hadn't been certified since 10.6, because Apple said that they'd no longer bother after that, but apparently I was wrong and 10.12 is certified (though apparently only UNIX03, which is a bit surprising because I've not found anything from UNIX08 missing and many of the UNIX08 additions were originally in macOS). The most interesting one on the list is Huawei EulerOS 2.0 - as far as I know this is the first Linux distribution to be certified UNIX.
And yet if you buy an off-the-shelf filer from NetApp or EMC it will be x86 hardware running FreeBSD. It turns out that you can beat 256 threads all playing cache-line ping-pong with fewer faster hardware threads that let your software threads share L1 cache.
A few things things. The first is that they always had a larger market than SPARC, so their economies of scale were a bit better. The second is the HPC market. IBM doesn't put many PowerPC chips in supercomputers, but they charge a lot for the ones that they do, which helps offset R&D costs. Third, a lot of game consoles used PowerPC chips. These weren't the same designs as the high-end POWER systems (since POWER3, POWER implements the PowerPC spec and is just a marketing term for the expensive PowerPC systems), but they often shared some of the same pipelines and so could split the cost. They also consolidated their Z-series and PowerPC teams. Z-series is a fairly extreme CISC architecture, so is pretty different from PowerPC, but they now both use the same FPU designs (including hardware binary-coded decimal and a few other weird and wonderful things). This, again, reduces their costs.
The other big difference is that IBM kept evolving PowerPC. SPARCv9 is still a clean RISC architecture that would be recognisable to the RISC II team at Berkeley in the '80s. It's not great as a modern compiler target.
The root problem was that single-thread performance of Sparc lagged Intel x86 around the time the PIII came out
Depends a bit on the SPARC, but the real problem was lack of volume. You could still buy faster SPARCs around that time, but they cost an order of magnitude more for a 10-20% performance improvement. If 20% means a lot to you, then you're going to start looking seriously at SMP and often a little bit of refactoring could buy you a 20+% improvement with a dual-processor system, which cost only a little bit more than double the price of the single-processor system.
Sun's goal for VirtualBox as to make it a gateway drug for their Xen + Solaris + proprietary management tools stack. The idea was that VirtualBox would make it easy to create small numbers of VMs for managing infrastructure, but when you got to a larger scale you'd want to buy the bigger system. Now that Oracle has started dabbling in the cloud provider space, they may start caring again for the same reason.
They open sourced the verilog for the T1, but very few people did anything with it. There's a cut-down FPGA version that a few people use for teaching, but that's about it. I wouldn't be too surprised at this point if Oracle became an ARM licensee. The interesting things on their recent SPARC processors have been database and crypto offload engines, not the CPU cores, and this would let them outsource the cost of CPU, toolchain, and OS development.
PostgreSQL is less of a threat to Oracle than MySQL. If you start building a system with PostgreSQL, you have a reliable database with a decent query optimiser and you'll end up putting a lot of logic into the database. Once you grow to a big enough size that you might be able to afford Oracle, they send along salesmen and convince your least competent C?O that your data would be a lot safer if you migrate to a proper database and they provide migration tools to do this. They can probably demonstrate some speedups from their custom filesystem and query optimiser. On the other hand, if you start with MySQL, you end up using the database as little more than a key-value store and put most of the logic outside of the database. It's much harder to demo a place where Oracle is an improvement because your bottleneck is the application logic that's doing a load of redundant database queries, not the database itself.
The numbers aren't quite as bad as you make them seem. In Florida, a lot of the electricity consumption is air conditioning, which is at its highest during the day when solar is generating. Generating a lot of power when the AC is off is less useful, because that's not where the demand spikes are. Nuclear only gets a capacity factor of 0.9 if it's being used as base load, which means if other things are demand-following and can even out peaks and troughs in generation.
A homeowner here can't sell energy back to the utility. Only those who can produce 24 hours a day on-demand can do so
Which is partly to do with the energy markets not currently being designed to scale. The spot price of electricity varies second by second and a lot of power plants adjust their outputs based on this. Some big storage facilities buy power when it's cheap, pump water uphill, and then run as a hydro-electric power plant when the spot price is high. Having a lot more sources varying their output but not being able to adjust output down or up based on the current price will cause a lot of problems for the existing infrastructure.
The story isn't that some people behave badly, it's that other people designed a system that is reliant on people not behaving badly for security, which is pretty braindead.
I don't live in the US, but during our partial eclipse a few years back I was able to look at the sun and had to remind myself to use filters or look away quickly.
First of all, this whole mania about not looking at the sun ever is absurd. People do it all the time between eclipses with no lasting damage.
People do it all the time, and then look away immediately because it causes their eyes to water and then hurt. The problem during an eclipse is that the amount of sunlight hitting your retina is still up in the range where it can cause damage, but not in the range where you'll notice immediately. It's a similar issue to sunburn on cloudy days: because less IR is hitting your skin, you don't realise that you're still absorbing a lot of UV and so end up burning even when you don't feel that warm. You've evolved a set of danger reflexes for things that damaged a large proportion of your potential ancestors, not for the rarer events.
You're thinking in terms of code. In much business software, it's more about the embedded data that's proprietary and confidential. Details of contracts, price calculations, and so on, can all easily end up embedded, or details of internal infrastructure (or a partner's infrastructure) that's commercially sensitive. All of this needs auditing before you can open source proprietary code.
There are plenty of codebases that simply don't involve anything like that. If you were smart enough to use only libraries to which you could link freely to begin with, then you don't have that kind of work to do.
Sure, unless the software is purely internal but contains business logic (i.e. most internal software in the category that you describe), in which case you still need to audit it to ensure that it doesn't contain anything proprietary from your partners.
You'll be paying in terms of power consumption and heat, which may trigger thermal throttling elsewhere. Either way, it's hard to imagine that generating a high-resolution image and not downsampling it is more expensive than generating a high-resolution image and downsampling it, which is what the grandparent was claiming.
Slashdot Mirror
A lot of former Self and StrongTalk people went to work on v8 (and later Dart and WebAssembly) at Google. If you look at Dart, you can see that it's very much StrongTalk-with-braces. If you look at the name of the project lead, you'll understand why.
The 'secure enclave' scheme is 100% pure 'security through obscurity'.
Nonsense. The secure enclave is a separate ARM core that has its own private memory and is designed so that you can write keys to it and it will do signing and encryption / decryption on your behalf, but you can't exfiltrate the keys. A similar design appears in a few Android devices, but the lack of uniformity means that most software doesn't make good use of it. There are valid criticisms of iOS device security, but this one just makes you look like an idiot.
$235 doesn't sound like a great idea for the developing world. I'd be quite tempted by one for those specs once LineageOS is running on it.
Apparently it's not dead, but for those of us for whom this is the first time that we've heard it (other than as the first version of Android, which, thankfully, is dead), what is it?
this same thing happens naturally as well, the price of the ads being determined by the value they give for the advertisers, the ads will just be cheaper to run per click in the same proportion there are fake clicks. it doesn't solve the problem that people are stupid enough to sign up to something, install something or to buy something advertised in such a way.
The flaw in your logic is that advertising space is limited. Remember those late '90s pages that were 90% banner ads? There's a reason that they died. Price per click goes down, but only towards a minimum generated by the fact that companies are bidding for the same space. The goal is to make the cost of online advertising higher than the value of online advertising (various analysts believe that it's very close to that point now).
Probably. Both, at launch, looked pretty much like an updated PalmOS and fairly similar to Symbian Series 60. Most of the common UI elements between iOS and Android were found in at least one, if not both, of those prior smartphone operating systems.
I didn't, but I'm not surprised. Last time I spoke to someone at Oracle, they said that the revenue from the DB was up, but they had very few new customers. Their real problem is Moore's law and friends. In the early '90s, payroll for a moderately large company took a serious database on high-end hardware to manage, with several hours of compute time to complete the payroll calculations each week. Now, that same company is maybe 10 times the size, but you can buy a computer more than 100 times better in terms of RAM, storage capacity, storage speed, and processor speed, for a few hundred dollars. On a modern machine, you don't need carefully optimised queries and carefully designed on-disk data structures - you can probably fit the whole thing in RAM and run the computations in Lua and still get the whole thing done in a second or two. At one end of the market, most customers can now run their systems with cheap commodity hardware and software. At the other end of the market, companies like Facebook and Google have more data than Oracle can easily handle and couldn't afford Oracle license fees even if there was a viable Oracle product for them to buy. The middle is gradually shrinking.
V8 has been largely rewritten now, but a lot of the original code was from Anamorphic Smalltalk, which was bought and BSD licensed by Sun.
I was going to reply saying that macOS hadn't been certified since 10.6, because Apple said that they'd no longer bother after that, but apparently I was wrong and 10.12 is certified (though apparently only UNIX03, which is a bit surprising because I've not found anything from UNIX08 missing and many of the UNIX08 additions were originally in macOS). The most interesting one on the list is Huawei EulerOS 2.0 - as far as I know this is the first Linux distribution to be certified UNIX.
And yet if you buy an off-the-shelf filer from NetApp or EMC it will be x86 hardware running FreeBSD. It turns out that you can beat 256 threads all playing cache-line ping-pong with fewer faster hardware threads that let your software threads share L1 cache.
A few things things. The first is that they always had a larger market than SPARC, so their economies of scale were a bit better. The second is the HPC market. IBM doesn't put many PowerPC chips in supercomputers, but they charge a lot for the ones that they do, which helps offset R&D costs. Third, a lot of game consoles used PowerPC chips. These weren't the same designs as the high-end POWER systems (since POWER3, POWER implements the PowerPC spec and is just a marketing term for the expensive PowerPC systems), but they often shared some of the same pipelines and so could split the cost. They also consolidated their Z-series and PowerPC teams. Z-series is a fairly extreme CISC architecture, so is pretty different from PowerPC, but they now both use the same FPU designs (including hardware binary-coded decimal and a few other weird and wonderful things). This, again, reduces their costs.
The other big difference is that IBM kept evolving PowerPC. SPARCv9 is still a clean RISC architecture that would be recognisable to the RISC II team at Berkeley in the '80s. It's not great as a modern compiler target.
The root problem was that single-thread performance of Sparc lagged Intel x86 around the time the PIII came out
Depends a bit on the SPARC, but the real problem was lack of volume. You could still buy faster SPARCs around that time, but they cost an order of magnitude more for a 10-20% performance improvement. If 20% means a lot to you, then you're going to start looking seriously at SMP and often a little bit of refactoring could buy you a 20+% improvement with a dual-processor system, which cost only a little bit more than double the price of the single-processor system.
Sun's goal for VirtualBox as to make it a gateway drug for their Xen + Solaris + proprietary management tools stack. The idea was that VirtualBox would make it easy to create small numbers of VMs for managing infrastructure, but when you got to a larger scale you'd want to buy the bigger system. Now that Oracle has started dabbling in the cloud provider space, they may start caring again for the same reason.
They open sourced the verilog for the T1, but very few people did anything with it. There's a cut-down FPGA version that a few people use for teaching, but that's about it. I wouldn't be too surprised at this point if Oracle became an ARM licensee. The interesting things on their recent SPARC processors have been database and crypto offload engines, not the CPU cores, and this would let them outsource the cost of CPU, toolchain, and OS development.
PostgreSQL is less of a threat to Oracle than MySQL. If you start building a system with PostgreSQL, you have a reliable database with a decent query optimiser and you'll end up putting a lot of logic into the database. Once you grow to a big enough size that you might be able to afford Oracle, they send along salesmen and convince your least competent C?O that your data would be a lot safer if you migrate to a proper database and they provide migration tools to do this. They can probably demonstrate some speedups from their custom filesystem and query optimiser. On the other hand, if you start with MySQL, you end up using the database as little more than a key-value store and put most of the logic outside of the database. It's much harder to demo a place where Oracle is an improvement because your bottleneck is the application logic that's doing a load of redundant database queries, not the database itself.
Uh, I meant 2002. Apparently typing is too hard.
Have laptops not been detecting falling situations from far before this came along?
The earliest reference I can find to hard drive fall sensors had IBM shipping them around 2032, so four years after this patent.
The numbers aren't quite as bad as you make them seem. In Florida, a lot of the electricity consumption is air conditioning, which is at its highest during the day when solar is generating. Generating a lot of power when the AC is off is less useful, because that's not where the demand spikes are. Nuclear only gets a capacity factor of 0.9 if it's being used as base load, which means if other things are demand-following and can even out peaks and troughs in generation.
A homeowner here can't sell energy back to the utility. Only those who can produce 24 hours a day on-demand can do so
Which is partly to do with the energy markets not currently being designed to scale. The spot price of electricity varies second by second and a lot of power plants adjust their outputs based on this. Some big storage facilities buy power when it's cheap, pump water uphill, and then run as a hydro-electric power plant when the spot price is high. Having a lot more sources varying their output but not being able to adjust output down or up based on the current price will cause a lot of problems for the existing infrastructure.
The story isn't that some people behave badly, it's that other people designed a system that is reliant on people not behaving badly for security, which is pretty braindead.
I don't live in the US, but during our partial eclipse a few years back I was able to look at the sun and had to remind myself to use filters or look away quickly.
First of all, this whole mania about not looking at the sun ever is absurd. People do it all the time between eclipses with no lasting damage.
People do it all the time, and then look away immediately because it causes their eyes to water and then hurt. The problem during an eclipse is that the amount of sunlight hitting your retina is still up in the range where it can cause damage, but not in the range where you'll notice immediately. It's a similar issue to sunburn on cloudy days: because less IR is hitting your skin, you don't realise that you're still absorbing a lot of UV and so end up burning even when you don't feel that warm. You've evolved a set of danger reflexes for things that damaged a large proportion of your potential ancestors, not for the rarer events.
You're thinking in terms of code. In much business software, it's more about the embedded data that's proprietary and confidential. Details of contracts, price calculations, and so on, can all easily end up embedded, or details of internal infrastructure (or a partner's infrastructure) that's commercially sensitive. All of this needs auditing before you can open source proprietary code.
There are plenty of codebases that simply don't involve anything like that. If you were smart enough to use only libraries to which you could link freely to begin with, then you don't have that kind of work to do.
Sure, unless the software is purely internal but contains business logic (i.e. most internal software in the category that you describe), in which case you still need to audit it to ensure that it doesn't contain anything proprietary from your partners.
You'll be paying in terms of power consumption and heat, which may trigger thermal throttling elsewhere. Either way, it's hard to imagine that generating a high-resolution image and not downsampling it is more expensive than generating a high-resolution image and downsampling it, which is what the grandparent was claiming.