Incidentally, you cannot boot into X, that is just some userspace-stuff your distro is doing to fake it. Boot is long over at that time.
If you are going to play that game, I've written BIOS's. Grub was my userspace. By your standards the kernel is so far removed from where the real action is, it could hardly be considered relevant to booting.
(I'm sort of hoping Intel's microcode guys pop up here, and tell us both we are so far away from the real metal we may as well be discussing how Kubernetes gets it's config from etcd. They'd be wrong of course. The machine ain't up until I can Google something.)
Please, for the love of $deity, lets this be true. We've been putting up with broken video on, well, just about every Intel GPU since they stated their driver update for Gen9 (Skylake). And that includes older hardware that used to work before this effort was started. I can understand the occasional glitch in a new kernel, but "doesn't boot into X, at all, ever" isn't just a glitch - and it's been going on for 5 kernels so far. Currently in 4.5 I can't reliably attach a second monitor.
What amazes me is this isn't just Linux. The net was full of people complaining the video their brand new Windows laptop ranges from slow to utterly unusable. Naturally they said are going to get it fixed under warranty. Ha! It infests everything. The BIOS on my laptop can't initialise a second monitor either.
It is getting better. 4.2 didn't boot for me. 4.5 works acceptably on one screen. The i915's bugzilla reports my current two monitor problem is fixed. Hell, maybe I'll be able switch on full GPU power saving in 4.7! But is it really this hard?
At least were I live it has nothing to do with renewables (the sun ain't shining at that time after all). Oddly it is because coal plants suffer the same problem renewables - they can't control the power quickly. No one is using power at the coal plants are producing at 3 AM so there is an oversupply, and it's costs more to shut the plant down for the hour or so than it does to pay people to find ways to use it.
This happens just about every fucking day! How is this news?
Anyhow the price for making the SE sw write-once is that you could have to recall, scrap and replace an entire production run (as in million of units).
No, it's doesn't have to be that serious. The price is the Secure Enclave destroys the secrets it's guarding before allowing an upgrade. In effect, it's the same as purchasing a new phone.
Even if it is was you say, there is always another alternative - live with the bug. It is after all a question of what you consider to be the biggest bug - your privacy stuff not being really private, or the remote chance you turn the phone off after a few failed password attempts.
Using actual ROMs or PROMs would be an effective defense, but those are getting pretty rare these days.
On the contrary, they are the cheapest way to place firmware on a chip. And more to the point, something has to boot the chip to the point it can load real firmware. If you allow whatever does that booting to upgraded, you are also allowing it to be corrupted and the device (CPU, phone, or whatever) to be bricked. How many bricked CPU's have you seen? I'd wager none. That's because they all have ROM. It's not rare at all.
Do you *really* want law enforcement to build the capacity to attack the silicon?
It's expensive - far more expensive than getting a judge to sign a piece of paper. And it's not easy. In fact it's very, very hard. The security of SIM's, Credit and Debit cards, pay TV encryption, ATM's and a long list of other things rely on silicon guarding it's secrets. If you don't have several million, a gear normally found only in Uni's and chip manufacturers, a few PhD's and months of time it's out of the question.
So, no I don't want it. And I'm not particularly worried about them building it.
That's not the solution - Apple needs to be able to update the Secure Enclave firmware too, it's too complex to be reasonable to bake into a ROM forever.
TPM's are more complex, simply because the solve a more general version of the same problem. Billions have been sold, and most of them have got along just fine without a firmware upgrade. We do know how to get bugs below 1 per 100k LOC, and I have no doubt Apple is capable of it. It's not cheap, but I doubt the expense concerns them overly.
You can't update the security enclave as it is flashed once and then it burns a circuit that makes it impossible to update again.
Source? It would be nice if it was true, but if it's true I'd expect to hear Apple trumpeting it from the roof tops. As far a I know, Apple have never said anything publicly. The reference document they publish on security says nothing about firmware upgrades for the Secure Enclave.
And Apple also knows the Secure Enclave can be by-passed too, by anybody who has the firmware signing key. If you have it, you just upload new firmware bypassing the checks. Currently only Apple has it of course. But that is where this all started.
Still, they should make the FBI rue the day they tried to destroy Apple's market,
Which is real simple to do. Put the Secure Enclave firmware in ROM, so it can't be upgraded. Then it becomes truly uncrackable from software, so the LEA's would be reduced to attacking the silicon. It's their worst nightmare.
This is possible because the SecureEnclave is stand-alone, and compared iOS itself it is almost trivial. It's unlikely the API it provides is ever going to change. Besides, there is a public standardised API for such things: TPM 2.0. (Not that Apple's into standards, but TPM 2.0 is documented and thoroughly vetted, and includes rate limiting for passwords.) The one remaining reason to provide upgrades is to fix a bug, but as the old saying goes "only trivial software contains no bugs", and for someone of Apples resources this, to repeat myself, trivial. Besides in things like Secure Enclave's allowing firmware upgrades IS A BUG.
We already have the connector. It has 24 pins, can carry up to 100W, and has 4 dedicated high speed pairs rated up to 40Gbps. It's specification already allows for different signalling to take over the pins in what the spec calls Alternate Modes. There are Alternate Modes for Display Port, MHL and Thunderbolt. These are in addition to the native mode - USB 3.1
It's the USB-C connector of course. The idea of making Ethernet an alternate has already been mooted. Someone just has to do the work to make it happen.
Google worries about ad blockers - then turns off all bar the most obtrusive positioning of their ads.
Google search ads were occasionally useful. Useful enough for me to want to keep them there. I actually clicked on them when looking for stuff to buy. But then they moved them to the top, then altered the colours so they were barely distinguishable from real search results. That was when I turned on ad blocking for their search page. I guess I could have just blocked the ads at the top and been happy, but it was too much work. Now the option is gone, so procrastination won the day!
If Google wanted to treat me like the customer instead of the cow to be milked they would ask me where to display the ads, and we would both win. As it is I get an ad free service and they whinge about ad blockers. Some things are just inexplicable.
There is a long list of cognitive biases to which ALL humans with biological brains and nervous systems are susceptible.
https://en.wikipedia.org/wiki/...
Good lord. What a list. I didn't realise scammers, conmen, marketers, politicians and religious leaders had so much raw material to work with.
The top hit is a 2001 article about something that never happened. The second hit is of course correct - there is even a seal.
It's truely amazing the non-GMO nutters have managed to keep that first hit at the top for 14 years. They must want it to be true so much they are linking to it, clicking on it, citing it like crazy.
As I said, it sums up the debate nicely. If that is what you were intending - well done.
So if governments around the world are giving themselves license to hack into our stuff, do anything they please, and share this with other governments... then it almost seems like a moral duty that every government server is now fair game.
The people in power always have always read, listened to, or saw pretty much whatever they wanted, although possibly they had to pause to spin the reason into a "so the terrorists don't win" or "think of the children" meme. And with "people in power" I don't just mean the politicians, or the spooks. Judges assume they can extract information by just issuing an writ to hand over documents, and its almost considered "due diligence" now for employers to launch MITM attacks on in https connections their employees make (although not the CEO's, obviously). Collectively one of or other of them can (and on occasion do) open every letter, listen to every phone call, and read every SMS sent by a person. As soon at the technology became available they used radio mics to listen to every word uttered at a place or by a person in real time, later they blanketed cities with cameras. So there is nothing new in this - they just want the abilities they had in 20th century back.
What is utterly beyond explanation is they apparently think they can do it. It is true that every man has his price. As we found out, even a large corporation like AT&T had its price, a price the NSA was prepared to pay. But this time they are dealing with physics and maths, and they apparently think they can force physics and maths to change if they throw the law at it, or man power at it, or money at it.
To them I say: it's time to move on old men. You're tilting at windmills, and don't even know it.
Of course you can, syntax notwithstanding. But asking questions here is an awful way to learn the capabilities of Rust given they have published a free online book to teach you just that. It would only take you a day to work through the entire thing. It being open source and all, once you have done that next step would be to look up the code for the standard libraries for that that does something like you want. There is nothing like studying the work of an expert in the field to get you up to speed fast. They even give an example that looks like yours in the standard library doco.
I didn't say lines of code is good way to measure productivity. Using it as such a measure is counter productive because programmers find ways to bloat the code. Not only doesn't it increase real productivity, it creates a maintenance nightmare.
What I said was programmers produce the similar lines of code per day, regardless of language. If you are doubt this, you need to go study some more. It's been demonstrated over and over again. There are many things that do effect lines of code delivered of course - the biggest one being project size. Most programmers can deliver a 200 line debugged, working program in a day. Put the same programmer in a large project, and that can drop to 10 lines of code per day, which is far larger effect than language.
You are right in that lines produced per day by a programmer is effected by language - but It's nothing like 20 to 1. This page shows 4 to 1 at the extreme; Smalltalk vs Assembler, with the assembler programmer producing 4 times as many lines of code as the smalltalk programmer. I guess that's to be expected give how much a meaning a smalltalk programmer can put into one line vs an assembler programmer. If you look at languages that are more similar - eg curly brace languages, you see a difference of only 2 to 1.
If you look closely, you notice another odd thing. The less lines the programmers write, the more productive they are in delivering function points in general. Now if I had of said because the C programmer writes code faster than Rust productive, he will be less productive I'm sure you would have jumped on me from an even greater height and you would have managed to be more wrong than you are now. I don't know whether it's true for C and Rust, but "the more code a language lets you write in a day, the less productive you will be in it" is definitely a good rule of thumb. In the smalltalk vs assembler case, the smalltalk programmer delivers 3 times as many function points as the assembler program per unit time, while writing 1/4 of the amount of code! If it is true for C and Rust, it annihilates your suggestion that over the life of a project C would be more productive that a Rust.
Lines of code is not the measure of productivity when two thirds of them require debugging or rewriting because the idiot didn't know what they were doing and used a hammer to drive a screw.
True. Which is why it isn't measured that way. The usual measure is the total non comment lines delivered over the total time it took to deliver the project, divided by the number of people employed to do it - and that doesn't just include programmers. Here "delivered" means debugged and in production. Which is how a large project ends with with abysmal figures like 10 lines per day. If a language encourages buggy code, which is thrown away that counts against it, not for it.
Rust should add rudimentary support for exceptions
It does have exactly that, rudimentary being the operative word. It has panic(), which doesn't kill the program but does kill a much larger unit of it (a thread actually) then try/except/finally normally controls. Still, it's enough to recover from things like out of memory, because it guarantees the memory will be freed.
The reason it has only rudimentary exceptions is because it can do the by combining it's type inference engine with it's spectacularly powerful macroing system. The type system allows you return arbitrary stuff with the caller really having to know or care (because it has an implicit type generation), and they have provided a "try!" macro in the standard library. So it's all there, just not done in the conventional way.
And in case you are wondering why force you to learn this newfangled way when the old way worked perfectly well - it's because the old way imposed run time over heads on everything. The new way handles it in the type system so overheads disappear at compile time.
It's just a repeat of Rust's memory handling solution, really. In C you handle memory allocation and exceptions manually, with all sorts of nasty consequences like dangling pointers and people dereferencing NULL. Java/C#/YouNameIt eliminates the nasty consequences using run time solutions like gc and exceptions - but they impose a runtime overhead. Rust brings something totally new to the table - the programmer handles it, but the language eliminates all the nasty consequences. So it's fast like C, and safe like Java/C#/YouNameIt. But there is nothing free in this world. Rust's extracts it's pound of programmer flesh with it's borrow checker.
Rust targets LLVM, and LLVM outputs the same debugging info as the GNU compilers. So gdb, for example, works as well with Rust as it does with C.
more productivity (since you know C better)
For a short while. (OK, maybe not so sort in Rust's case as borrow checker is a bitch.) But in the end no, a Rust programmer will beat C with the same inevitability a newbie C programmer will eventually beat an experienced assembly programmer. The reason is the same too. You need far less lines of Rust to do the same thing. Programmers tend to produce the same number of lines of code per day, regardless of language.
there are C compilers available for almost every piece of hardware out there.
There are. But most of those CPU arches targeted by LLVM, which is what the current Rust compiler uses as it's back end. And then there are some targeted by LLVM, but not but C - like asm.js.
You were right, once. If you were targeting some random arch the only thing you could rely on was a C compiler being available for some definition of "C". If you were lucking they might even provide something that looked vaguely like the POSIX library. But LLVM has broken that rule of thumb. The odds are very good that LLVM will also target your machine, and if it does all compilers and languages that use LLVM can produce code for it. And this isn't for some random implementation of the language like you got with C, it is typically the reference implementation of the language, and you get all this bits of it standard library that are written in itself as well.
After 40 so years, they world has finally moved on.
But maybe he is talking about a different species of developer entirely - the one that publish most of the crap found in app stores. When I think "developer", I think of a person who enjoys creating new things from code. That is the sort of developer who is driving openpilot, which is were most of the innovation is happening right now. The developer he is apparently talking about prioritises money - they are people who constantly looking to make the most money in the shortest amount of time from the least amount of code. A different animal entirely. We will need them later to find all the useful things that can be done with drones. But right now it's a struggle to make the thing work at all, and for that you need real developers.
Real developers? Sorry. That was a bad choice of words. What is a socially acceptable word for people who prefer technology to money, or indeed people. Nerds maybe? Call us what we like, were are far too busy having fun with computers to notice.
In a gasoline engine, how much fuel do you feed to the air? When do you trigger the spark plugs, at what advance? In a diesel, when do you inject the fuel, and how much? Etc...
Yeah, but it's the mechanical engineers job to optimise those parameters. He then tells the software engineer he needs the oxygen level adjusted within 5ms of sensing a change in the throttle. If software engineer stares at him and says "how the fuck I am supposed to meet that deadline on the lame arse 100Mhz 16 bit CPU the electrical engineers gave me when the brake guys are telling me I need to react to wheel slip within 100us otherwise I could kill somebody?". The mechanical engineer will then shrug his shoulders and say "I don't know, that's not my area, but if you don't do it we won't meet emissions standards".
The only way to fix this PR mess was to own up, take it on this chin, and move on. That way they might have a hope of selling the "I was a bad boy but I've learnt my lesson so you can be sure I'll never do it again" line. Blaming the most remote limb, hacking it off, and saying to the world "there I've fixed the problem" sounds awfully like psychopaths are running the show. If that is true we know as soon as a backs are turned, they will do it again.
The problem, as I see it, is that by doing it in Javascript, we're introducing a new dependency: the code will only work on a browser produced in 2015.
Well you can rest easy then, because no one is writing this stuff in JavaScript.
What triggered this change is Emscripten, which is a back end for LLVM that targets... JavaScript. Actually it targets asm.js, which runs at about 1/2 native speed in Firefox (not so fast in Chrome, because Google thinks the solution to the same problem is NaCl).
What that means is any compiler that uses LLVM can now compile to asm.js. Which means any program written in Python, Rust, Go (there are a whole pile of languages) can now be compiled to run in the browser. In particular Clang is a C compiler for LLVM. Dosbox is a x86 + MSDOS emulator, written in C. Ergo Dosbox can now be compiled to JavaScript and this run in the browser. Js-dos is a site apparently dedicated hosting games that does just that. The game console emulators are also written in C. So they to can and now have been compiled to asm.js. Because modern web browsers support WebGL, OpenGL games that have been open sourced (like Quake3) have also been compiled to JavaScript, and run spookelly well. Which is how we get to the plethora of games mentioned in the article. Pity it didn't mention the technology behind it.
But why stop a games? Sqlite3 has been recompiled for Javascript. It can do in browser SQL queries in about 2ms, and is a damned site nicer to use than wandering through a spiderweb of Javascript objects. But why stick to something sane? You can now do ffmpeg encoding in your browser.
Imagine how the dating scene would change if men could get off (legally, cleanly and guilt free) whenever the had the urge, instead of having to date countless women and pretend to like them to get laid until the right one came along.....
Errr, have you looked at what internet offers now? Admittedly you only get to touch the screen, but there is a real woman behind it who gets paid to do what you ask and pretend to love it without caring one wit about whether you like her or not.
Maybe you haven't paid much attention to it, but the women on the planet sure have. There reaction was exactly the same as this time round - they embark on crusades to get rid of porn on the internet. Hopefully their successes to date will be an excellent predictor of Dr Kathleen Richardson's success in this time around.
Despite these developments civilisation still stands. My guess is that's because men actually enjoy the company of their partner, particularly one that also reciprocates by appreciating his company as much as he appreciates hers.
The only surprising thing about any of this is as an ethicist lecturing at a University, I expect Dr Kathleen Richardson to be smart enough to recognise we have been inventing machines designed to replace women in sex for literally millennia - starting with his hands. Yet they always end up wanting the real thing. Maybe, just maybe, isn't just sex isn't the only thing men want from a relationship?
Slashdot Mirror
Incidentally, you cannot boot into X, that is just some userspace-stuff your distro is doing to fake it. Boot is long over at that time.
If you are going to play that game, I've written BIOS's. Grub was my userspace. By your standards the kernel is so far removed from where the real action is, it could hardly be considered relevant to booting.
(I'm sort of hoping Intel's microcode guys pop up here, and tell us both we are so far away from the real metal we may as well be discussing how Kubernetes gets it's config from etcd. They'd be wrong of course. The machine ain't up until I can Google something.)
Please, for the love of $deity, lets this be true. We've been putting up with broken video on, well, just about every Intel GPU since they stated their driver update for Gen9 (Skylake). And that includes older hardware that used to work before this effort was started. I can understand the occasional glitch in a new kernel, but "doesn't boot into X, at all, ever" isn't just a glitch - and it's been going on for 5 kernels so far. Currently in 4.5 I can't reliably attach a second monitor.
What amazes me is this isn't just Linux. The net was full of people complaining the video their brand new Windows laptop ranges from slow to utterly unusable. Naturally they said are going to get it fixed under warranty. Ha! It infests everything. The BIOS on my laptop can't initialise a second monitor either.
It is getting better. 4.2 didn't boot for me. 4.5 works acceptably on one screen. The i915's bugzilla reports my current two monitor problem is fixed. Hell, maybe I'll be able switch on full GPU power saving in 4.7! But is it really this hard?
Here is a graph of electricity prices where I live for the current day: http://www.aemo.com.au/Electricity/Data/Price-and-Demand/Price-and-Demand-Graphs/Current-Dispatch-Interval-Price-and-Demand-Graph-QLD. Note the red line (whole sale price) drops off the bottom graph in the small hours of the morning. It's negative.
At least were I live it has nothing to do with renewables (the sun ain't shining at that time after all). Oddly it is because coal plants suffer the same problem renewables - they can't control the power quickly. No one is using power at the coal plants are producing at 3 AM so there is an oversupply, and it's costs more to shut the plant down for the hour or so than it does to pay people to find ways to use it.
This happens just about every fucking day! How is this news?
Anyhow the price for making the SE sw write-once is that you could have to recall, scrap and replace an entire production run (as in million of units).
No, it's doesn't have to be that serious. The price is the Secure Enclave destroys the secrets it's guarding before allowing an upgrade. In effect, it's the same as purchasing a new phone.
Even if it is was you say, there is always another alternative - live with the bug. It is after all a question of what you consider to be the biggest bug - your privacy stuff not being really private, or the remote chance you turn the phone off after a few failed password attempts.
Using actual ROMs or PROMs would be an effective defense, but those are getting pretty rare these days.
On the contrary, they are the cheapest way to place firmware on a chip. And more to the point, something has to boot the chip to the point it can load real firmware. If you allow whatever does that booting to upgraded, you are also allowing it to be corrupted and the device (CPU, phone, or whatever) to be bricked. How many bricked CPU's have you seen? I'd wager none. That's because they all have ROM. It's not rare at all.
Do you *really* want law enforcement to build the capacity to attack the silicon?
It's expensive - far more expensive than getting a judge to sign a piece of paper. And it's not easy. In fact it's very, very hard. The security of SIM's, Credit and Debit cards, pay TV encryption, ATM's and a long list of other things rely on silicon guarding it's secrets. If you don't have several million, a gear normally found only in Uni's and chip manufacturers, a few PhD's and months of time it's out of the question.
So, no I don't want it. And I'm not particularly worried about them building it.
That's not the solution - Apple needs to be able to update the Secure Enclave firmware too, it's too complex to be reasonable to bake into a ROM forever.
TPM's are more complex, simply because the solve a more general version of the same problem. Billions have been sold, and most of them have got along just fine without a firmware upgrade. We do know how to get bugs below 1 per 100k LOC, and I have no doubt Apple is capable of it. It's not cheap, but I doubt the expense concerns them overly.
You can't update the security enclave as it is flashed once and then it burns a circuit that makes it impossible to update again.
Source? It would be nice if it was true, but if it's true I'd expect to hear Apple trumpeting it from the roof tops. As far a I know, Apple have never said anything publicly. The reference document they publish on security says nothing about firmware upgrades for the Secure Enclave.
that's why the 5S and newer have Secure Enclave.
And Apple also knows the Secure Enclave can be by-passed too, by anybody who has the firmware signing key. If you have it, you just upload new firmware bypassing the checks. Currently only Apple has it of course. But that is where this all started.
Still, they should make the FBI rue the day they tried to destroy Apple's market,
Which is real simple to do. Put the Secure Enclave firmware in ROM, so it can't be upgraded. Then it becomes truly uncrackable from software, so the LEA's would be reduced to attacking the silicon. It's their worst nightmare.
This is possible because the SecureEnclave is stand-alone, and compared iOS itself it is almost trivial. It's unlikely the API it provides is ever going to change. Besides, there is a public standardised API for such things: TPM 2.0. (Not that Apple's into standards, but TPM 2.0 is documented and thoroughly vetted, and includes rate limiting for passwords.) The one remaining reason to provide upgrades is to fix a bug, but as the old saying goes "only trivial software contains no bugs", and for someone of Apples resources this, to repeat myself, trivial. Besides in things like Secure Enclave's allowing firmware upgrades IS A BUG.
We already have the connector. It has 24 pins, can carry up to 100W, and has 4 dedicated high speed pairs rated up to 40Gbps. It's specification already allows for different signalling to take over the pins in what the spec calls Alternate Modes. There are Alternate Modes for Display Port, MHL and Thunderbolt. These are in addition to the native mode - USB 3.1
It's the USB-C connector of course. The idea of making Ethernet an alternate has already been mooted. Someone just has to do the work to make it happen.
Google worries about ad blockers - then turns off all bar the most obtrusive positioning of their ads.
Google search ads were occasionally useful. Useful enough for me to want to keep them there. I actually clicked on them when looking for stuff to buy. But then they moved them to the top, then altered the colours so they were barely distinguishable from real search results. That was when I turned on ad blocking for their search page. I guess I could have just blocked the ads at the top and been happy, but it was too much work. Now the option is gone, so procrastination won the day!
If Google wanted to treat me like the customer instead of the cow to be milked they would ask me where to display the ads, and we would both win. As it is I get an ad free service and they whinge about ad blockers. Some things are just inexplicable.
There is a long list of cognitive biases to which ALL humans with biological brains and nervous systems are susceptible. https://en.wikipedia.org/wiki/...
Good lord. What a list. I didn't realise scammers, conmen, marketers, politicians and religious leaders had so much raw material to work with.
[Citation] [lmgtfy.com]
Was that meant to be helpful, or misleading or a very subtle but clever statement about the GM debate?
The top two hits are in order: ...
FDA's new regulations won't allow non-GMO, GMO-free label
Huge Victory: USDA Introduces Official Non-GMO Label
The top hit is a 2001 article about something that never happened. The second hit is of course correct - there is even a seal.
It's truely amazing the non-GMO nutters have managed to keep that first hit at the top for 14 years. They must want it to be true so much they are linking to it, clicking on it, citing it like crazy.
As I said, it sums up the debate nicely. If that is what you were intending - well done.
Seems to me that it would be a faulty design that requires a 'cable' to need any electronics at all.
In that case USB 3.1 must be a terrible design. A full spec cable doesn't just require a resistor or two, it needs a PCB: http://cache-www.belkin.com/resources/img/overview/f2cu029/USB-C_CableExploded_v01-r01.png. That cable is only rated for 3A. A full spec cable can carry 5A. I'm surprised they only cost $20.
Mind you, I'm not complaining. $20 sounds like a cheap price to pay if I get to throw out the rats nest of cables I carry around now.
So if governments around the world are giving themselves license to hack into our stuff, do anything they please, and share this with other governments ... then it almost seems like a moral duty that every government server is now fair game.
The people in power always have always read, listened to, or saw pretty much whatever they wanted, although possibly they had to pause to spin the reason into a "so the terrorists don't win" or "think of the children" meme. And with "people in power" I don't just mean the politicians, or the spooks. Judges assume they can extract information by just issuing an writ to hand over documents, and its almost considered "due diligence" now for employers to launch MITM attacks on in https connections their employees make (although not the CEO's, obviously). Collectively one of or other of them can (and on occasion do) open every letter, listen to every phone call, and read every SMS sent by a person. As soon at the technology became available they used radio mics to listen to every word uttered at a place or by a person in real time, later they blanketed cities with cameras. So there is nothing new in this - they just want the abilities they had in 20th century back.
What is utterly beyond explanation is they apparently think they can do it. It is true that every man has his price. As we found out, even a large corporation like AT&T had its price, a price the NSA was prepared to pay. But this time they are dealing with physics and maths, and they apparently think they can force physics and maths to change if they throw the law at it, or man power at it, or money at it.
To them I say: it's time to move on old men. You're tilting at windmills, and don't even know it.
Can you go:
Of course you can, syntax notwithstanding. But asking questions here is an awful way to learn the capabilities of Rust given they have published a free online book to teach you just that. It would only take you a day to work through the entire thing. It being open source and all, once you have done that next step would be to look up the code for the standard libraries for that that does something like you want. There is nothing like studying the work of an expert in the field to get you up to speed fast. They even give an example that looks like yours in the standard library doco.
Lines of code is not the measure of productivity
I didn't say lines of code is good way to measure productivity. Using it as such a measure is counter productive because programmers find ways to bloat the code. Not only doesn't it increase real productivity, it creates a maintenance nightmare.
What I said was programmers produce the similar lines of code per day, regardless of language. If you are doubt this, you need to go study some more. It's been demonstrated over and over again. There are many things that do effect lines of code delivered of course - the biggest one being project size. Most programmers can deliver a 200 line debugged, working program in a day. Put the same programmer in a large project, and that can drop to 10 lines of code per day, which is far larger effect than language.
You are right in that lines produced per day by a programmer is effected by language - but It's nothing like 20 to 1. This page shows 4 to 1 at the extreme; Smalltalk vs Assembler, with the assembler programmer producing 4 times as many lines of code as the smalltalk programmer. I guess that's to be expected give how much a meaning a smalltalk programmer can put into one line vs an assembler programmer. If you look at languages that are more similar - eg curly brace languages, you see a difference of only 2 to 1.
If you look closely, you notice another odd thing. The less lines the programmers write, the more productive they are in delivering function points in general. Now if I had of said because the C programmer writes code faster than Rust productive, he will be less productive I'm sure you would have jumped on me from an even greater height and you would have managed to be more wrong than you are now. I don't know whether it's true for C and Rust, but "the more code a language lets you write in a day, the less productive you will be in it" is definitely a good rule of thumb. In the smalltalk vs assembler case, the smalltalk programmer delivers 3 times as many function points as the assembler program per unit time, while writing 1/4 of the amount of code! If it is true for C and Rust, it annihilates your suggestion that over the life of a project C would be more productive that a Rust.
Lines of code is not the measure of productivity when two thirds of them require debugging or rewriting because the idiot didn't know what they were doing and used a hammer to drive a screw.
True. Which is why it isn't measured that way. The usual measure is the total non comment lines delivered over the total time it took to deliver the project, divided by the number of people employed to do it - and that doesn't just include programmers. Here "delivered" means debugged and in production. Which is how a large project ends with with abysmal figures like 10 lines per day. If a language encourages buggy code, which is thrown away that counts against it, not for it.
Rust should add rudimentary support for exceptions
It does have exactly that, rudimentary being the operative word. It has panic(), which doesn't kill the program but does kill a much larger unit of it (a thread actually) then try/except/finally normally controls. Still, it's enough to recover from things like out of memory, because it guarantees the memory will be freed.
The reason it has only rudimentary exceptions is because it can do the by combining it's type inference engine with it's spectacularly powerful macroing system. The type system allows you return arbitrary stuff with the caller really having to know or care (because it has an implicit type generation), and they have provided a "try!" macro in the standard library. So it's all there, just not done in the conventional way.
And in case you are wondering why force you to learn this newfangled way when the old way worked perfectly well - it's because the old way imposed run time over heads on everything. The new way handles it in the type system so overheads disappear at compile time.
It's just a repeat of Rust's memory handling solution, really. In C you handle memory allocation and exceptions manually, with all sorts of nasty consequences like dangling pointers and people dereferencing NULL. Java/C#/YouNameIt eliminates the nasty consequences using run time solutions like gc and exceptions - but they impose a runtime overhead. Rust brings something totally new to the table - the programmer handles it, but the language eliminates all the nasty consequences. So it's fast like C, and safe like Java/C#/YouNameIt. But there is nothing free in this world. Rust's extracts it's pound of programmer flesh with it's borrow checker.
However, in my brief glance over I can't see any way to allocate a block of memory at runtime
Jeezze, you weren't kidding when you said brief. An Overview of Memory Management in Rust.
You'll get better debugging tools
Rust targets LLVM, and LLVM outputs the same debugging info as the GNU compilers. So gdb, for example, works as well with Rust as it does with C.
more productivity (since you know C better)
For a short while. (OK, maybe not so sort in Rust's case as borrow checker is a bitch.) But in the end no, a Rust programmer will beat C with the same inevitability a newbie C programmer will eventually beat an experienced assembly programmer. The reason is the same too. You need far less lines of Rust to do the same thing. Programmers tend to produce the same number of lines of code per day, regardless of language.
there are C compilers available for almost every piece of hardware out there.
There are. But most of those CPU arches targeted by LLVM, which is what the current Rust compiler uses as it's back end. And then there are some targeted by LLVM, but not but C - like asm.js.
You were right, once. If you were targeting some random arch the only thing you could rely on was a C compiler being available for some definition of "C". If you were lucking they might even provide something that looked vaguely like the POSIX library. But LLVM has broken that rule of thumb. The odds are very good that LLVM will also target your machine, and if it does all compilers and languages that use LLVM can produce code for it. And this isn't for some random implementation of the language like you got with C, it is typically the reference implementation of the language, and you get all this bits of it standard library that are written in itself as well.
After 40 so years, they world has finally moved on.
There are delevelopers taking it to the next level. They are the same ones that have got it to where it is now - like autonomous plans that find people people lost the wilderness and drop a rescue package beside them.
But maybe he is talking about a different species of developer entirely - the one that publish most of the crap found in app stores. When I think "developer", I think of a person who enjoys creating new things from code. That is the sort of developer who is driving openpilot, which is were most of the innovation is happening right now. The developer he is apparently talking about prioritises money - they are people who constantly looking to make the most money in the shortest amount of time from the least amount of code. A different animal entirely. We will need them later to find all the useful things that can be done with drones. But right now it's a struggle to make the thing work at all, and for that you need real developers.
Real developers? Sorry. That was a bad choice of words. What is a socially acceptable word for people who prefer technology to money, or indeed people. Nerds maybe? Call us what we like, were are far too busy having fun with computers to notice.
In a gasoline engine, how much fuel do you feed to the air? When do you trigger the spark plugs, at what advance? In a diesel, when do you inject the fuel, and how much? Etc...
Yeah, but it's the mechanical engineers job to optimise those parameters. He then tells the software engineer he needs the oxygen level adjusted within 5ms of sensing a change in the throttle. If software engineer stares at him and says "how the fuck I am supposed to meet that deadline on the lame arse 100Mhz 16 bit CPU the electrical engineers gave me when the brake guys are telling me I need to react to wheel slip within 100us otherwise I could kill somebody?". The mechanical engineer will then shrug his shoulders and say "I don't know, that's not my area, but if you don't do it we won't meet emissions standards".
The only way to fix this PR mess was to own up, take it on this chin, and move on. That way they might have a hope of selling the "I was a bad boy but I've learnt my lesson so you can be sure I'll never do it again" line. Blaming the most remote limb, hacking it off, and saying to the world "there I've fixed the problem" sounds awfully like psychopaths are running the show. If that is true we know as soon as a backs are turned, they will do it again.
The problem, as I see it, is that by doing it in Javascript, we're introducing a new dependency: the code will only work on a browser produced in 2015.
Well you can rest easy then, because no one is writing this stuff in JavaScript.
What triggered this change is Emscripten, which is a back end for LLVM that targets ... JavaScript. Actually it targets asm.js, which runs at about 1/2 native speed in Firefox (not so fast in Chrome, because Google thinks the solution to the same problem is NaCl).
What that means is any compiler that uses LLVM can now compile to asm.js. Which means any program written in Python, Rust, Go (there are a whole pile of languages) can now be compiled to run in the browser. In particular Clang is a C compiler for LLVM. Dosbox is a x86 + MSDOS emulator, written in C. Ergo Dosbox can now be compiled to JavaScript and this run in the browser. Js-dos is a site apparently dedicated hosting games that does just that. The game console emulators are also written in C. So they to can and now have been compiled to asm.js. Because modern web browsers support WebGL, OpenGL games that have been open sourced (like Quake3) have also been compiled to JavaScript, and run spookelly well. Which is how we get to the plethora of games mentioned in the article. Pity it didn't mention the technology behind it.
But why stop a games? Sqlite3 has been recompiled for Javascript. It can do in browser SQL queries in about 2ms, and is a damned site nicer to use than wandering through a spiderweb of Javascript objects. But why stick to something sane? You can now do ffmpeg encoding in your browser.
WinIoT is ... based on WinCE.
WinCE?
*shudder*
Even Microsoft has dropped that basket case, when they moved WinPhone from CE to NT.
Why anybody would use it when Microsoft is making Windows 10 available for free on the Pi 2 is beyond me.
Imagine how the dating scene would change if men could get off (legally, cleanly and guilt free) whenever the had the urge, instead of having to date countless women and pretend to like them to get laid until the right one came along.....
Errr, have you looked at what internet offers now? Admittedly you only get to touch the screen, but there is a real woman behind it who gets paid to do what you ask and pretend to love it without caring one wit about whether you like her or not.
Maybe you haven't paid much attention to it, but the women on the planet sure have. There reaction was exactly the same as this time round - they embark on crusades to get rid of porn on the internet. Hopefully their successes to date will be an excellent predictor of Dr Kathleen Richardson's success in this time around.
Despite these developments civilisation still stands. My guess is that's because men actually enjoy the company of their partner, particularly one that also reciprocates by appreciating his company as much as he appreciates hers.
The only surprising thing about any of this is as an ethicist lecturing at a University, I expect Dr Kathleen Richardson to be smart enough to recognise we have been inventing machines designed to replace women in sex for literally millennia - starting with his hands. Yet they always end up wanting the real thing. Maybe, just maybe, isn't just sex isn't the only thing men want from a relationship?