Especially if they've set the thread priorities correctly. The compilation thread should have a lower priority than the interpreter thread, so it will run in the gaps where the interpreter is waiting for input (and a little bit anyway). The interpreted code will be slower than compiled, and may remain interpreted[1] for longer, but the compiler won't be preempting the real work, as happens when they do it synchronously.
[1] 'Interpreted' in V8 really means compiled with no optimisations.
I tried Google Maps a bit, and then switched to OSMAnd. It was about the only Google app I used, although I don't know if the Android Browser is developed anymore now that Google has shifted all of their focus to Chrome. I would love to be able to get a reasonable Android phone with F-Droid installed as the default market and no Google stuff.
Apple has 7.68% of the desktop market and 15.42% of the mobile market. They can pull a lot of stuff without getting into trouble because they don't have anything like the market share required to exert undue influence on the market. When they have larger shares, for example in the online music distribution market a few years ago, they do get investigated.
Your comment makes as much sense as complaining that your corner shop doesn't get into trouble for doing things that would be the target of antitrust investigations if Walmart did them. Apple is a highly profitable niche player, but still a niche player. They can't use their dominant position in one market to gain prominence in another because they don't have a dominant position in any market and haven't since the iPod.
Intel does the former quite successfully, but it does cause problems internally. Promotions and so on are often linked to project success, yet projects can be cancelled simply because Intel had 5 guesses about what the market would want a few years down the line and your group was given one of the ones that didn't turn out to be accurate to work on. This leads to resentment and competent engineers realising that they have more prospects for advancement if they go and work for competitors. It's hard to get right: you often do want multiple teams working on different solutions to the same problem, because it gives you a fallback, but no one wants to be working on the one that gets cancelled (this is increasingly a problem at Google too).
Actually, it is. Google is charging between $0.5 and $2 for manufacturers to bundle their apps, depending on what they bundle, and also restricting what else they're allowed to ship. They're trying very hard to do to the mobile phone market what Microsoft did to the PC market: make the hardware a cheap, interchangeable, commodity and their software the bit that customers are willing to pay for. Oh, and on the subject of Microsoft, don't forget that they're charging around $15/device for the patents of theirs that probably (i.e. might, but it would cost too much to have a court find out) infringes. Even if you don't do any customisation, Android is likely to end up costing the manufacturer around $20/device.
From what I've heard from ex-Nokia people, it wasn't just senior management that lacked direction. They had internal teams all developing complete stacks in isolation and competing for resources. Elop wasn't completely wrong: making them all focus on a single platform was probably the only thing that could have saved Nokia, and Windows Phone wasn't a completely ludicrous choice, as they did want something to differentiate themselves from the competition and there weren't any other significant Windows Phone vendors to compete with.
Pushing ahead with Linux + Qt might have worked, but only if they'd fired about 90% of middle management and reorganised the teams. Even then, there would likely have been a lot of resentment from the various teams that had their work discarded in favour of another's. Remember that Nokia didn't have a Linux + Qt platform, they had several, all with mutually incompatible frameworks built atop Qt, none of which was compellingly better than the others.
It's a shame that the Qt on EKA2 project was killed. The EKA2 kernel was a much better fit for mobile devices than Linux (it still amazes me after all of Google's investment how few of its features Android has), and Qt would have given them the base of a modern development environment that would have competed well with other platforms.
They had a rough go with Qt/Maemo, then they changed course, to a dead end street.
Was Maemo ever Qt? I thought they changed the name when they switched it from GTK to Qt. And there you see the real problem with Nokia: a complete lack of direction. They had, in EKA2, a beautifully designed kernel for mobile applications, tied to a userland and userspace APIs that were designed when 1MB of RAM was an insane quantity reserved for the most expensive of phones. So, the first thing they did was try to shoehorn Linux into a phone. Then, having replaced the one good bit of their stack with Linux, they had a load of competing projects to provide a replacement UI, leading to a plethora of short-lived APIs, just as everyone else was realising that third-party developers are the key to a successful platform.
Not really. How many people do you think can deliver tons of salt and grit (in quantities of a factor of ten more than they normally sell you) at a few days notice, in unusually bad weather? And if you find someone, then you have to distribute it (something that's usually done in the summer, when the roads are clear and you can put it in strategic locations where the gritting trucks can easily collect it.
Bad weather isn't a problem, unexpected bad weather is. Where I used to live (in the UK, so no red vs blue today), we had one day of snow pretty much every year. The city council decided to be very cautious and ensured that they had enough salt and grit available to keep the roads clear if they had a one-week snowfall. One year, we had two weeks of solid snowfall and temperatures below freezing and the whole place ground to a halt. Meanwhile, places a bit further north were fine because they typically had snow all winter and so had prepared for it. Now, you could argue that my council should have prepared for the snow better, but in the 10 years that I lived there I only saw more than one day a year of snow that one winter - maintaining the equipment reserves to handle it every year would have been expensive and you can bet people would have complained about the waste of taxpayers' money.
No, he's in the Ecuadorian embassy, which is on British soil. Britain does not regard foreign embassies as foreign soil (neither do most countries). The Geneva Convention prohibits forced entry into embassies and grants diplomatic immunity to anyone within them. This means that people in an embassy are still covered by the laws of the host country, but the only redress that the host nation has is to deport them as soon as they leave the embassy.
Often, he knows just a little bit more about the subject than the person hiring him and that's enough to convince them that he knows a lot more. From there, he's in a position of authority and so people believe whatever nonsense he spouts, because they don't know enough to contradict him. I've seen this in quite a few small businesses whose core competence is not computer related - they hire someone to 'do their IT' at a rate that is close to what they pay secretaries, they get the only kind of person willing to do skilled work at that kind of rate (i.e. someone who isn't very competent), but that person knows more about the IT stuff than management and so they assume that he knows a lot. It usually isn't too big a disaster, until you find out that they've been keeping their entire dadabase (which isn't even in first normal form) of all customers and orders in a single Access DB, which isn't backed up, is stored on a USB stick 'for security' and the manager who just quit took it with him...
You might look at Centaur. They make much heavier use of formal verification in their chip designs (in collaboration with UTexas) than Intel. Intel has the luxury of being able to afford to throw manpower at testing and simulation, Centaur (being much smaller) has to spend their time and manpower as efficiently as possible to compete.
There's a lot of work on provably correct software. Probably the most advanced currently is the NICTA group behind seL4. They estimate that the developer time (and therefore cost) is around 30 times greater than writing good (well documented, with a test suite providing good coverage) software without verification, which is significantly cheaper than previous efforts. It is worth it for things like seL4: a microkernel that is at the core of your TCB and provides guarantees. It's not clear yet that the cost will scale linearly with the size of the software, so 30 times is a pretty conservative estimate. 100 times is probably more likely.
You don't need to be God to write correct software, you just need to put more than a couple of orders of magnitude more time and effort into it than you would for normal code. This includes making sure that you have a machine-readable specification that defines what 'correct' actually means. If your customer is willing to pay for this, then they can get correct software. Now, good luck finding a customer who is willing to pay 100 times more for the difference between 'mostly working' and 'formally verified'.
Exactly. I have no problem with rulings like this, as long as Valve can be sued for fraud if they use the words 'buy', 'own' or 'purchase' anywhere in their advertising. A quick glance that the Steam web site shows it listing 'Top Sellers' and says 'buy it once, play on Mac, PC or Linux'. If they are not allowing you to buy the game, then this is fraudulent advertising.
I work with Peter Neumann, so I don't need a history lesson on MULTICS. The code is available now, if you want to take a look at it - it's very simple compared to a modern UNIX.
If Slashdot didn't die the LAST three or four times they revamped the site (no matter how much everyone knew it would), it sure as hell won't die with this one.
Each of the last times, they made some things better and some things worse, and they fixed the worst regressions before they forced everyone to move to the new version. Now, they have made the site basically unusable. I've been here for about 10 years and was in the top 5 most active commenters for a couple of quarters of that, and I'm still no on beta. If I do get forced to move to beta, then goodbye Slashdot.
Code written by government employees on government time can't be copyrighted (there is an issue for SELinux here, where some new files had GPL headers slapped on them and can't actually be GPL'd because they were written by NSA employees). This is code written by people on DARPA-funded grants working in universities and private companies, so that rule doesn't apply.
I'm currently funded on a DARPA grant, and we release most of our code under BSD or Apache licenses (quite a bit of it is already rolled back into FreeBSD). As I'm a UK citizen working for a UK university, there is no restriction at all on whether I can copyright things, but our contract with DARPA strongly encourages us to release code under permissive licenses.
Note that this is not a new release of code by DARPA, it's just a centralised place for tracking all of the places where DARPA has funded code that's been released as open source.
If you consider people who reuse libraries instead of rewriting everything from scratch to be script kiddies, then I hope I never have to use any code that you've written...
I don't work in avionics, so I can't speak for that field, but in computing, I do feel qualified to speak - more so than most, as I spent some time working full time for a computer history collection and am still closely involved with computer history preservation efforts. Comparing computing today with the '40s wouldn't make sense, so we'll go with the '60s. As I said in the post that you replied to, back then software was almost entirely single-use, throw-away code. I have read quite a bit of source code from that era, and much of it contains obvious bugs. It's also really, really trivial.
Complex payroll programs from back then that took a day or two to run would be a couple of lines of SQL today and would complete in a fraction of a second. They'd also be a lot less buggy (one anecdote I collected from someone who worked at a large steelworks was that their payroll program was required to print every intermediate step in the calculations on the wage slips so that employees could check them for errors, and they often found them because bugs in the program caused incorrect values to propagate into some places. Today, being unable to correctly do a payroll for a factory would be likely to make the news).
For anyone who gets too nostalgic about this era, I'd recommend that they read the programmers' manual for the Stantec ZEBRA (1958), which states that the 150 instruction limitation for assembly programs is not a significant problem, because no one could possibly write a working program that complex. They were not wrong, according to the ZEBRA programmers that I talked to: even 100-instruction programs were likely to contain so many bugs that there was little point even trying to run them. You'd be hard pressed today to find a programmer who couldn't write a working program an order of magnitude more complex than the most complicated thing ever to run on such a machine.
That's true, if you assume that the economy is a simple zero-sum model with no feedback effects. The point of a subsidy in this regard can be either:
It is cost effective in the long run, but the payback time is such that it's not currently possible to persuade private industry to do it. The net effect of the project on the economy will be such that increased tax revenues will pay back the subsidy (if not directly from the power plant then from all of the additional industry that it makes possible).
That the plant itself won't be profitable, but it will stimulate demand in other areas (by having a big consumer of PV panels, you create demand for PV panels), which will promote economies of scale in production and lower the price. This will cause the PV panel production industry to expand (more taxes) and will lower prices so that other industries that are made possible by cheap PV panels will grow (more taxes). It will also mean that India has a large production base for PV panels to export to the world (more taxes, more export trade, stronger currency).
In both of these cases, the subsidy is a good investment for the government, but would be a bad investment for private industry (with the possible exception of very large companies that have subsidiaries in a very broad range of endeavours).
to reject a pull request that eliminates a gendered pronoun on the principle that pronouns should in fact be gendered would constitute a fireable offense for me and for Joyent
Translation: Joylent likes poor English. I hope they never try to get this documentation turned into a book, because a professional copyeditor would end up flagging every single use of 'they' and telling them to turn it into a he or she. The next comment says:
To me, that insistence can only come from one place: that gender—specifically, masculinity—is inextricably linked to software, and that's not an attitude that Joyent tolerates
Which is bullshit. My publisher (Pearson) uses a fairly standard set of style guides and they explicitly require correct English usage with pronouns (hint: 'they' is not a singular pronoun), and recommend either alternating he and she in examples or using she entirely. If your documentation is using 'he' exclusively, then it may be bad, but that's not a problem with this commit, it's a general problem with your poor quality docs.
This entire blog post reads like something that would put off women from participating in the project: pandering to the notion that women are precious little flowers who will be mortally offended by a pronoun.
Slashdot Mirror
[1] 'Interpreted' in V8 really means compiled with no optimisations.
I tried Google Maps a bit, and then switched to OSMAnd. It was about the only Google app I used, although I don't know if the Android Browser is developed anymore now that Google has shifted all of their focus to Chrome. I would love to be able to get a reasonable Android phone with F-Droid installed as the default market and no Google stuff.
Apple has 7.68% of the desktop market and 15.42% of the mobile market. They can pull a lot of stuff without getting into trouble because they don't have anything like the market share required to exert undue influence on the market. When they have larger shares, for example in the online music distribution market a few years ago, they do get investigated.
Your comment makes as much sense as complaining that your corner shop doesn't get into trouble for doing things that would be the target of antitrust investigations if Walmart did them. Apple is a highly profitable niche player, but still a niche player. They can't use their dominant position in one market to gain prominence in another because they don't have a dominant position in any market and haven't since the iPod.
Intel does the former quite successfully, but it does cause problems internally. Promotions and so on are often linked to project success, yet projects can be cancelled simply because Intel had 5 guesses about what the market would want a few years down the line and your group was given one of the ones that didn't turn out to be accurate to work on. This leads to resentment and competent engineers realising that they have more prospects for advancement if they go and work for competitors. It's hard to get right: you often do want multiple teams working on different solutions to the same problem, because it gives you a fallback, but no one wants to be working on the one that gets cancelled (this is increasingly a problem at Google too).
Actually, it is. Google is charging between $0.5 and $2 for manufacturers to bundle their apps, depending on what they bundle, and also restricting what else they're allowed to ship. They're trying very hard to do to the mobile phone market what Microsoft did to the PC market: make the hardware a cheap, interchangeable, commodity and their software the bit that customers are willing to pay for. Oh, and on the subject of Microsoft, don't forget that they're charging around $15/device for the patents of theirs that probably (i.e. might, but it would cost too much to have a court find out) infringes. Even if you don't do any customisation, Android is likely to end up costing the manufacturer around $20/device.
From what I've heard from ex-Nokia people, it wasn't just senior management that lacked direction. They had internal teams all developing complete stacks in isolation and competing for resources. Elop wasn't completely wrong: making them all focus on a single platform was probably the only thing that could have saved Nokia, and Windows Phone wasn't a completely ludicrous choice, as they did want something to differentiate themselves from the competition and there weren't any other significant Windows Phone vendors to compete with.
Pushing ahead with Linux + Qt might have worked, but only if they'd fired about 90% of middle management and reorganised the teams. Even then, there would likely have been a lot of resentment from the various teams that had their work discarded in favour of another's. Remember that Nokia didn't have a Linux + Qt platform, they had several, all with mutually incompatible frameworks built atop Qt, none of which was compellingly better than the others.
It's a shame that the Qt on EKA2 project was killed. The EKA2 kernel was a much better fit for mobile devices than Linux (it still amazes me after all of Google's investment how few of its features Android has), and Qt would have given them the base of a modern development environment that would have competed well with other platforms.
They had a rough go with Qt/Maemo, then they changed course, to a dead end street.
Was Maemo ever Qt? I thought they changed the name when they switched it from GTK to Qt. And there you see the real problem with Nokia: a complete lack of direction. They had, in EKA2, a beautifully designed kernel for mobile applications, tied to a userland and userspace APIs that were designed when 1MB of RAM was an insane quantity reserved for the most expensive of phones. So, the first thing they did was try to shoehorn Linux into a phone. Then, having replaced the one good bit of their stack with Linux, they had a load of competing projects to provide a replacement UI, leading to a plethora of short-lived APIs, just as everyone else was realising that third-party developers are the key to a successful platform.
Not really. How many people do you think can deliver tons of salt and grit (in quantities of a factor of ten more than they normally sell you) at a few days notice, in unusually bad weather? And if you find someone, then you have to distribute it (something that's usually done in the summer, when the roads are clear and you can put it in strategic locations where the gritting trucks can easily collect it.
Bad weather isn't a problem, unexpected bad weather is. Where I used to live (in the UK, so no red vs blue today), we had one day of snow pretty much every year. The city council decided to be very cautious and ensured that they had enough salt and grit available to keep the roads clear if they had a one-week snowfall. One year, we had two weeks of solid snowfall and temperatures below freezing and the whole place ground to a halt. Meanwhile, places a bit further north were fine because they typically had snow all winter and so had prepared for it. Now, you could argue that my council should have prepared for the snow better, but in the 10 years that I lived there I only saw more than one day a year of snow that one winter - maintaining the equipment reserves to handle it every year would have been expensive and you can bet people would have complained about the waste of taxpayers' money.
The Geneva Convention
For some reason, probably related to lack of coffee, I typed Geneva when I meant Vienna.
No, he's in the Ecuadorian embassy, which is on British soil. Britain does not regard foreign embassies as foreign soil (neither do most countries). The Geneva Convention prohibits forced entry into embassies and grants diplomatic immunity to anyone within them. This means that people in an embassy are still covered by the laws of the host country, but the only redress that the host nation has is to deport them as soon as they leave the embassy.
Often, he knows just a little bit more about the subject than the person hiring him and that's enough to convince them that he knows a lot more. From there, he's in a position of authority and so people believe whatever nonsense he spouts, because they don't know enough to contradict him. I've seen this in quite a few small businesses whose core competence is not computer related - they hire someone to 'do their IT' at a rate that is close to what they pay secretaries, they get the only kind of person willing to do skilled work at that kind of rate (i.e. someone who isn't very competent), but that person knows more about the IT stuff than management and so they assume that he knows a lot. It usually isn't too big a disaster, until you find out that they've been keeping their entire dadabase (which isn't even in first normal form) of all customers and orders in a single Access DB, which isn't backed up, is stored on a USB stick 'for security' and the manager who just quit took it with him...
Huh? That video starts at exactly the same point the one I posted does.
You might look at Centaur. They make much heavier use of formal verification in their chip designs (in collaboration with UTexas) than Intel. Intel has the luxury of being able to afford to throw manpower at testing and simulation, Centaur (being much smaller) has to spend their time and manpower as efficiently as possible to compete.
Start about 4 minutes in.
There's a lot of work on provably correct software. Probably the most advanced currently is the NICTA group behind seL4. They estimate that the developer time (and therefore cost) is around 30 times greater than writing good (well documented, with a test suite providing good coverage) software without verification, which is significantly cheaper than previous efforts. It is worth it for things like seL4: a microkernel that is at the core of your TCB and provides guarantees. It's not clear yet that the cost will scale linearly with the size of the software, so 30 times is a pretty conservative estimate. 100 times is probably more likely.
You don't need to be God to write correct software, you just need to put more than a couple of orders of magnitude more time and effort into it than you would for normal code. This includes making sure that you have a machine-readable specification that defines what 'correct' actually means. If your customer is willing to pay for this, then they can get correct software. Now, good luck finding a customer who is willing to pay 100 times more for the difference between 'mostly working' and 'formally verified'.
Exactly. I have no problem with rulings like this, as long as Valve can be sued for fraud if they use the words 'buy', 'own' or 'purchase' anywhere in their advertising. A quick glance that the Steam web site shows it listing 'Top Sellers' and says 'buy it once, play on Mac, PC or Linux'. If they are not allowing you to buy the game, then this is fraudulent advertising.
I work with Peter Neumann, so I don't need a history lesson on MULTICS. The code is available now, if you want to take a look at it - it's very simple compared to a modern UNIX.
If Slashdot didn't die the LAST three or four times they revamped the site (no matter how much everyone knew it would), it sure as hell won't die with this one.
Each of the last times, they made some things better and some things worse, and they fixed the worst regressions before they forced everyone to move to the new version. Now, they have made the site basically unusable. I've been here for about 10 years and was in the top 5 most active commenters for a couple of quarters of that, and I'm still no on beta. If I do get forced to move to beta, then goodbye Slashdot.
Code written by government employees on government time can't be copyrighted (there is an issue for SELinux here, where some new files had GPL headers slapped on them and can't actually be GPL'd because they were written by NSA employees). This is code written by people on DARPA-funded grants working in universities and private companies, so that rule doesn't apply.
I'm currently funded on a DARPA grant, and we release most of our code under BSD or Apache licenses (quite a bit of it is already rolled back into FreeBSD). As I'm a UK citizen working for a UK university, there is no restriction at all on whether I can copyright things, but our contract with DARPA strongly encourages us to release code under permissive licenses.
Note that this is not a new release of code by DARPA, it's just a centralised place for tracking all of the places where DARPA has funded code that's been released as open source.
If you consider people who reuse libraries instead of rewriting everything from scratch to be script kiddies, then I hope I never have to use any code that you've written...
They're still soliciting it. Stop whining here and send an email to feedback@slashdot.org.
I don't work in avionics, so I can't speak for that field, but in computing, I do feel qualified to speak - more so than most, as I spent some time working full time for a computer history collection and am still closely involved with computer history preservation efforts. Comparing computing today with the '40s wouldn't make sense, so we'll go with the '60s. As I said in the post that you replied to, back then software was almost entirely single-use, throw-away code. I have read quite a bit of source code from that era, and much of it contains obvious bugs. It's also really, really trivial.
Complex payroll programs from back then that took a day or two to run would be a couple of lines of SQL today and would complete in a fraction of a second. They'd also be a lot less buggy (one anecdote I collected from someone who worked at a large steelworks was that their payroll program was required to print every intermediate step in the calculations on the wage slips so that employees could check them for errors, and they often found them because bugs in the program caused incorrect values to propagate into some places. Today, being unable to correctly do a payroll for a factory would be likely to make the news).
For anyone who gets too nostalgic about this era, I'd recommend that they read the programmers' manual for the Stantec ZEBRA (1958), which states that the 150 instruction limitation for assembly programs is not a significant problem, because no one could possibly write a working program that complex. They were not wrong, according to the ZEBRA programmers that I talked to: even 100-instruction programs were likely to contain so many bugs that there was little point even trying to run them. You'd be hard pressed today to find a programmer who couldn't write a working program an order of magnitude more complex than the most complicated thing ever to run on such a machine.
In both of these cases, the subsidy is a good investment for the government, but would be a bad investment for private industry (with the possible exception of very large companies that have subsidiaries in a very broad range of endeavours).
to reject a pull request that eliminates a gendered pronoun on the principle that pronouns should in fact be gendered would constitute a fireable offense for me and for Joyent
Translation: Joylent likes poor English. I hope they never try to get this documentation turned into a book, because a professional copyeditor would end up flagging every single use of 'they' and telling them to turn it into a he or she. The next comment says:
To me, that insistence can only come from one place: that gender—specifically, masculinity—is inextricably linked to software, and that's not an attitude that Joyent tolerates
Which is bullshit. My publisher (Pearson) uses a fairly standard set of style guides and they explicitly require correct English usage with pronouns (hint: 'they' is not a singular pronoun), and recommend either alternating he and she in examples or using she entirely. If your documentation is using 'he' exclusively, then it may be bad, but that's not a problem with this commit, it's a general problem with your poor quality docs.
This entire blog post reads like something that would put off women from participating in the project: pandering to the notion that women are precious little flowers who will be mortally offended by a pronoun.