The Intel bits are vanilla, but even Intel don't make all the components on the board. I've got an Intel DX79SR, and its USB3 controller is by Renesas (formerly NEC). The USB3 controller has a firmware bug (that pauses the machine for a minute during every boot), which can be fixed by updating its firmware. The firmware can only be updated from Windows -- not just DOS but real Windows. I downloaded one of those (surely hooky) Windows rescue CDs, but even then the firmware updater refused to run, saying that "OLEDLG.DLL" wasn't found.
Thing is, I know what OLE is, I know what a DLG is, and I even know what a DLL is. And I know that there's no damn reason on earth for a firmware updater to need any of those things.
It's not that they're broken in themselves, it's that they've been added to a language that can't support them properly. People say, oooh, you must write exception-safe code. What they're saying is, there's a property the code needs to have, which a compiler cannot test for, which you can't even easily unit-test for. And without this property -- exception-safety -- the code is unsafe. (It's not the code that throws or catches exceptions that you need to worry about: it's routines whose callees might throw and whose callers might catch. Those routines have secondary control flows through them, ones you can't see, but which need to be correct for the program to be safe.)
It's not an innovation of the TDD community to say, that if something in your code isn't tested, you can't swear it works. In particular, you can't swear it will continue to work when future maintenance occurs. Because exception safety can't be "defended" against future breakage, I don't think you can hand-on-heart deliver C++ software written with exceptions and claim that it works.
I'm not against exceptions as a programming technique: I think they work great in managed languages such as Python, Java, or ML. In those languages, it's not possible to write code that isn't "exception-safe" in the C++ sense. That's where exceptions belong. Throwing exceptions through unmanaged code was a brave experiment on C++'s part, but it's a misfeature, and I've got more confidence in codebases which forbid that (despite whatever problems they have with two-stage initialisation) than codebases which don't.
Nor this http://survex.com/~olly/rheolism/: real Tetris in one line of BBC BASIC, 255 bytes after tokenisation. All the shapes are stored in one 32-bit constant. It's just amazing.
Since the first Iphone as such has become known as the "2G" and the second as the "3G", I suggest thinking of the Newton as the Iphone 1G. (OK, so there were a few different versions of the Newton itself. But at this distance in time, I think we can ignore that.)
He doesn't care about the e-mail client. He's trying to gauge whether he has total freedom to choose whatever tools he wants, or if the IT department pretty much dictates what he can or can't use.
Actually, it's not even really about whether developers individually get to choose the tools. It's about trying to gauge whether engineering as a whole has freedom to choose the tools, or whether it's imposed from above/outside. I've seen environments where literally the entire development team (including management) hates the source-control system, and the entire development plus QA teams (including management) hate the bug-tracking system, but corporate politics has left them with no mandate to get them changed against the wishes of the IT department. Perhaps that is indeed a rare pathology, but it's the one the question was intended to be diagnosing.
Pull a stunt like that and you'd strike out if I was interviewing you. To each their own, but fer christ sakes it is an email client not your main development tool!
Yes. That's why, as I said, I suggest paying attention to how they reply, not to which actual products they name.
After all, if you have major demands for extremely minor things like your email client, what kinds of demands are you going to asking for when it comes to actually doing your job?
For one thing, an email client is one of the primary tools of most jobs today, even software development jobs -- though I agree that in fact few, maybe none, are actually unusable.
But yes, the purpose of the question is very much for the interviewee to determine whether "major demands" for tools that are needed to actually do the job, such as source-control (which is why I indicated a harder line on that) are listened to or not. (It's not, as you seem to have inferred, a recommendation to make such demands at interview.) At the level I'd be interviewing at, for instance, you'd be taking me on not just for my experience in the design of software, but for my experience in the design of software-development organisations. The suggestion of "Babe Ruth" tooling isn't born from some prima-donna fantasy, it's the result of my having worked in both kinds of environments and seen the efficiency advantages. So that's one free piece of advice for your organisation without you even needing to have hired me.
What hardware/software am I expected to use at my desktop (e-mail, OS, editor, source control, etc.)?
This (certainly the email and source-control bits) is an excellent question to ask -- not so much because of what the answer as such, but because of your interviewers' reaction to giving the answer. If the interviewers frown or are apologetic about the answers, then that's a big clue that the IT department is run for its own convenience rather than the users' convenience.
For instance, if the email system in use is Outlook, ask if they have IMAP or SIMAP turned on, to enable non-Exchange clients. If the answer is no, then you know that uniformity gets enforced over convenience. You also know that nobody in the company uses any external mailing lists (such as the GCC or Linux kernel lists), as there's no way of posting to those from Exchange without looking like a fool.
If your interviewers sound cross or apologetic when describing the source-control system -- in other words, if the source-control system was dictated by IT without engineering buy-in -- then decline the job. Even if it were theoretically possible to do work in such a company, the excess overhead due to dealing with bureaucracy would make it an inefficient use of your time.
The absolute best answer you could get here is the one a VP of engineering whom I once worked for gave to a compiler vendor whose products we didn't want. "Can't you enforce tooling?", they asked him. "No," he said, "we don't tell Babe Ruth how to hold his bat."
Look at those large islands to the west of the Canaries. They're labelled Magnae Insulae Beati Brandani Branziliae Dictae: St Brandon's Large Islands, Called The Branzillas. Branzillas? Nobody used -zilla to mean "large" before Godzilla, and it didn't become really popular until Mozilla. The whole thing is clearly a forgery by some 21st-century geek, probably a Terry Gilliam fan, trying to mock up a folk etymology of the name "Brazil".;)
While dereferencing NULL is explicitly not permitted, pointer arithmetic on NULL is permitted, and dereferencing any non-NULL memory address is permitted.
Not any non-null memory address -- only one that points into an object. As there is no object whose address is the null pointer, the dereference is still undefined. And the compiler knows that.
Another way of looking at it is that tun->sk is equivalent to (*tun).sk, which is even more clearly undefined in C.
Technically, however, the C standard allows tun->sk to be a valid address, so removing the test is a semantically-invalid optimisation.
No. Technically, if tun is null, dereferencing it in the expression tun->sk invokes undefined behaviour -- not implementation-defined behaviour. It is perfectly valid to remove the test, because no strictly conforming code could tell the difference -- the game is already over once you've dereferenced a null pointer. This is a kernel bug (and not even, as Brad Spengler appears to be claiming, a new class of kernel bug); it's not a GCC bug.
But as other posters have said, it would indeed be a good security feature for GCC to warn when it does this.
It's a bit of a pain to explain why Firefox is the same thing as Ice Weasel.
"Because the Mozilla people have done something insane, egotistical, and counter-productive." There, that wasn't very painful.
As you imply, the reason that anyone who forks Firefox should be able to call the binaries their project produces firefox is the same reason that anyone who forks ls should be able to call the binary their project produces ls. Anything else just causes user confusion. If you want to have a trademark because you think you're so darn good that anyone else's version of your code just won't be the same, trademark your organisation name, not your project name. FSF Emacs vs XEmacs, FSF Glibc vs eglibc, coreutils ls vs BSD ls: there's no ambiguity in any of those cases.
By trademarking the name of the product, and imposing restrictions on uses of that trademark which affect people carrying out the normal processes of open-source natural selection, the Mozilla people have placed their own personal egos above the quality of the user experience. That's the sort of behaviour that open-source more usually comes as a blessed relief from.
That such restrictions on trademarked product names are allegedly compatible with open-source licences should be viewed as a bug in those licences, and Debian are absolutely right to call the Mozilla people on not being DFSG-free. If you want to pinpoint the moment they lost their way, it was when they trademarked "Mozilla" and named their foundation after it, and changed the mozilla tree so that it no longer built a binary called mozilla. If when they realised their "mistake" they'd changed the foundation name not the binary name, there'd be the Seamonkey Foundation's mozilla versus everyone else's mozilla, which would be perfectly straightforward, and they'd have generated much less ill will.
The mass market wants tick boxes, and customers wanted P4S. If you didn't have P4S, you didn't sell. It's sad and believe me it's true.
Right, it wouldn't have been so bad if the customers actually did want Plays-For-Sure. In fact, they just thought they wanted it -- or worse, perhaps we just thought they thought they wanted it.
Here is a story about Plays-For-Sure. The Rio Carbon was in some ways the poster child for Plays-For-Sure, and for Janus DRM: it was one of the players which Gates himself waved around at the launch event. I don't know how many we sold, but it was a lot. One day in late 2005, Microsoft accidentally revoked the Rio Carbon Janus licence. Or, rather, apparently, they rolled out a new version of the software in the Redmond DRM servers, which made WMP erroneously think that the Carbon licence had been revoked. Either way the effect was the same: for about six weeks until they pushed out a WMP hotfix, nobody anywhere in the world could transfer Plays-For-Sure protected content to their Rio Carbons. And during this six-week period, exactly five users noticed, one of whom was a former Rio employee. That tells you all you need to know about the extent to which consumers actually used or liked Plays-For-Sure.
What saddens me most is the thought of all the cool stuff that we could have implemented if we hadn't been wasting our time doing Plays-For-Sure.
I turned a corner and swear I saw him sitting there. I even said involuntarily "Hi, Prince..."
Stories like this make me wonder whether we actually hallucinate the presence of cats, maybe even people, all the time, and it's only when it happens after the cat has passed away that we think twice about such events and realise that they must have been hallucinations...
The RAID 5 this guy is talking about is controlled by one STUPID controller. There are a lot of methods, and patented technology that prevent just the situation he is talking about. Here is just one example: [...] Bad Sector Mapping and Media Patrol: These features scan the system's drive media to ensure that even bad physical drives do not impact data availability
I'm no RAID expert, but surely the 10^-14 bit error rate the guy is talking about is the rate of previously undiscovered errors? In which case, those errors won't have been found by a bad-sector sweep, nifty though that feature is for advance warning of other problems. His point is that one error in 10^14 bits, though it doesn't sound a lot, is actually one error every time you read 12TB of previously-working data. Which is what happens during RAID5 disk rebuild.
Notice how Microsoft patents, for example, are owned by Microsoft Corporation, not by the individual coders who came up with whatever algorithm/mechanism/whatever the company is trying to patent.
They're owned by Microsoft, but (AFAIK) the original inventor is still listed by name. When I was in this situation, that was the part that most rankled: that it was 100% the company's idea to file a patent for this stupidly broad and obvious idea, but that my own name would end up on the paperwork. So if this is the case for you too, perhaps you could try and persuade your boss, or someone else, that the conversations you had with them while developing the idea actually mean that they are the real inventor, and should have their name on the patent instead of yours.
FWIW the eventual outcome in my case was that the (UK) patent office rejected the patent, citing as prior art something so left-field that connecting it to the patent application seemed to me much more of an intellectual leap, than coming up with the idea we were trying to patent in the first place. Or, in other words, the company spend thousands of pounds on absolutely nothing and learned not to do that again. Which is a good outcome.
Without developer buy-in, whatever coding standards you come up with will be useless. IOW, ask your developers to create the standard together.
If you do this, at least filter it past someone who's a language expert before casting it in stone. I once worked somewhere where the official coding style for C demanded that structs were declared like this: "typedef struct _Foo {... } Foo_t". Either no-one knew, or no-one cared, that names starting with underscore are reserved to the standard library implementor, and that names ending with "_t" are reserved to Posix.
As it turned out, namespace pollution ended up not being among this company's biggest technical problems, but it did make knowledgeable developers feel that their professionalism was being wasted.
Interestingly, the Belgium joke was added to the American edition of Life, the Universe and Everything. In the original British edition the Rory was an award for the most gratuitous use of the word "fuck" in a serious screenplay.
Yes, but the Belgium joke actually predates that: it was in the second radio series, from which Life, The Universe And Everything was very loosely adapted. (Zaphod says it when about to fall out of the Nutrimatic cup.)
Right, I first learned about this from my GCSE Chemistry teacher in about 1986. He'd been in North Africa in the war, where supply convoys could easily be a couple of miles of a single line of traffic. Each jeep set off when it saw the one in front move, which meant that the ones at the back had to go hell-for-leather to catch up, only to realise that the ones at the front weren't going all that fast. There were regular ~100-jeep pile-ups until they instituted a system where everyone starts their engine and raises their hand when the driver in front does, then drops their hand and moves off when he does that -- which can be seen from a much greater distance along the line.
Perhaps tomorrow's embedded developers are programming today's desktops.
The desktop machine I learned to program on was an Acorn RiscPC. Later in life, I helped write the embedded firmware in the Rio Karma portable MP3 player. Rio Karma had two 90MHz ARM CPUs, 16Mbytes of RAM, and 20Gbytes of disk. That would have been one kick-ass RiscPC. If anything, programming and optimisation techniques learned on late-80s and early-90s desktops are too "embedded" for a lot of today's embedded programming.
And to those advocating hiring EE graduates for embedded programming: unless your device isn't far north of a toaster on the embeddedness scale, please also hire people with broader or higher-level software expertise for system design and architecture. It's not the same skill as squeezing one more instruction out of a loop, you find people with one skill and not the other, and any medium- or large-scale software project needs both skills (whether in the same person, or through good collaboration).
People go on about the spectrum of computing, software/assembler/logic/gates/transistors; what some don't realise is that there's a spectrum even within software. Some really good, tight, expert coders just can't see the bigger picture. I've seen medium-scale software architected by the toaster contingent: it wasn't pretty.
That calls into question how the duplicate was made.
Yes, exactly. I'm not questioning whether your friends heard something, I'm just expressing doubt that what they heard was clock jitter. It seems more likely that the duplicate was marginal in some way, resulting in the decoded data being different in the digital domain as well as the analog. (Most audio CD players, even ones from back in the day, can interpolate to produce fictional samples where the real sample can't be read due to bit errors. The results are -- listenable, but clearly not absolutely right.)
Turned out they could hear the difference between a master CD and a copy of the CD. The difference? Clock jitter. Yes, they could hear the effects of clock jitter.
If they can repeat this feat under laboratory conditions, it would be big news. Even a one-bit FIFO destroys any effect, measurable or audible, that clock jitter on the source CD has on components downstream of the FIFO -- but audio CD has much deeper than one-bit FIFOs to implement the error-correction. Neither the DAC (if present) or digital output (if not) of an audio CD player is directly clocked from the CD pits.
Not to rain on your parade, but the linked article does rather make the opposite point from what you're saying.
Analysts say that, and a journalist has linked it to HMV's falling profits. But look at what the article quotes Fopp themselves as saying: Fopp was "profitable and well regarded but had failed to gain support from stakeholders and suppliers"; they're seeking "reinstatement of the suppliers' licence to sell". Fopp weren't killed by Amazon or by Bittorrent, they were killed by the labels and distributors. It sounds rather as if the music industry, perhaps supported by more traditional supplicants such as HMV, objected to Fopp's policy of selling what people want to buy, at prices they're prepared to pay.
Peter (no connection to Fopp except repeat satisfied customer)
Slashdot Mirror
The Intel bits are vanilla, but even Intel don't make all the components on the board. I've got an Intel DX79SR, and its USB3 controller is by Renesas (formerly NEC). The USB3 controller has a firmware bug (that pauses the machine for a minute during every boot), which can be fixed by updating its firmware. The firmware can only be updated from Windows -- not just DOS but real Windows. I downloaded one of those (surely hooky) Windows rescue CDs, but even then the firmware updater refused to run, saying that "OLEDLG.DLL" wasn't found.
Thing is, I know what OLE is, I know what a DLG is, and I even know what a DLL is. And I know that there's no damn reason on earth for a firmware updater to need any of those things.
Peter
How are they broken?
It's not that they're broken in themselves, it's that they've been added to a language that can't support them properly. People say, oooh, you must write exception-safe code. What they're saying is, there's a property the code needs to have, which a compiler cannot test for, which you can't even easily unit-test for. And without this property -- exception-safety -- the code is unsafe. (It's not the code that throws or catches exceptions that you need to worry about: it's routines whose callees might throw and whose callers might catch. Those routines have secondary control flows through them, ones you can't see, but which need to be correct for the program to be safe.)
It's not an innovation of the TDD community to say, that if something in your code isn't tested, you can't swear it works. In particular, you can't swear it will continue to work when future maintenance occurs. Because exception safety can't be "defended" against future breakage, I don't think you can hand-on-heart deliver C++ software written with exceptions and claim that it works.
I'm not against exceptions as a programming technique: I think they work great in managed languages such as Python, Java, or ML. In those languages, it's not possible to write code that isn't "exception-safe" in the C++ sense. That's where exceptions belong. Throwing exceptions through unmanaged code was a brave experiment on C++'s part, but it's a misfeature, and I've got more confidence in codebases which forbid that (despite whatever problems they have with two-stage initialisation) than codebases which don't.
Peter
Nor this http://survex.com/~olly/rheolism/: real Tetris in one line of BBC BASIC, 255 bytes after tokenisation. All the shapes are stored in one 32-bit constant. It's just amazing.
Peter
Since the first Iphone as such has become known as the "2G" and the second as the "3G", I suggest thinking of the Newton as the Iphone 1G. (OK, so there were a few different versions of the Newton itself. But at this distance in time, I think we can ignore that.)
Peter
He doesn't care about the e-mail client. He's trying to gauge whether he has total freedom to choose whatever tools he wants, or if the IT department pretty much dictates what he can or can't use.
Actually, it's not even really about whether developers individually get to choose the tools. It's about trying to gauge whether engineering as a whole has freedom to choose the tools, or whether it's imposed from above/outside. I've seen environments where literally the entire development team (including management) hates the source-control system, and the entire development plus QA teams (including management) hate the bug-tracking system, but corporate politics has left them with no mandate to get them changed against the wishes of the IT department. Perhaps that is indeed a rare pathology, but it's the one the question was intended to be diagnosing.
Peter
Pull a stunt like that and you'd strike out if I was interviewing you. To each their own, but fer christ sakes it is an email client not your main development tool!
Yes. That's why, as I said, I suggest paying attention to how they reply, not to which actual products they name.
After all, if you have major demands for extremely minor things like your email client, what kinds of demands are you going to asking for when it comes to actually doing your job?
For one thing, an email client is one of the primary tools of most jobs today, even software development jobs -- though I agree that in fact few, maybe none, are actually unusable.
But yes, the purpose of the question is very much for the interviewee to determine whether "major demands" for tools that are needed to actually do the job, such as source-control (which is why I indicated a harder line on that) are listened to or not. (It's not, as you seem to have inferred, a recommendation to make such demands at interview.) At the level I'd be interviewing at, for instance, you'd be taking me on not just for my experience in the design of software, but for my experience in the design of software-development organisations. The suggestion of "Babe Ruth" tooling isn't born from some prima-donna fantasy, it's the result of my having worked in both kinds of environments and seen the efficiency advantages. So that's one free piece of advice for your organisation without you even needing to have hired me.
Peter
What hardware/software am I expected to use at my desktop (e-mail, OS, editor, source control, etc.)?
This (certainly the email and source-control bits) is an excellent question to ask -- not so much because of what the answer as such, but because of your interviewers' reaction to giving the answer. If the interviewers frown or are apologetic about the answers, then that's a big clue that the IT department is run for its own convenience rather than the users' convenience.
For instance, if the email system in use is Outlook, ask if they have IMAP or SIMAP turned on, to enable non-Exchange clients. If the answer is no, then you know that uniformity gets enforced over convenience. You also know that nobody in the company uses any external mailing lists (such as the GCC or Linux kernel lists), as there's no way of posting to those from Exchange without looking like a fool.
If your interviewers sound cross or apologetic when describing the source-control system -- in other words, if the source-control system was dictated by IT without engineering buy-in -- then decline the job. Even if it were theoretically possible to do work in such a company, the excess overhead due to dealing with bureaucracy would make it an inefficient use of your time.
The absolute best answer you could get here is the one a VP of engineering whom I once worked for gave to a compiler vendor whose products we didn't want. "Can't you enforce tooling?", they asked him. "No," he said, "we don't tell Babe Ruth how to hold his bat."
Peter
Look at those large islands to the west of the Canaries. They're labelled Magnae Insulae Beati Brandani Branziliae Dictae: St Brandon's Large Islands, Called The Branzillas. Branzillas? Nobody used -zilla to mean "large" before Godzilla, and it didn't become really popular until Mozilla. The whole thing is clearly a forgery by some 21st-century geek, probably a Terry Gilliam fan, trying to mock up a folk etymology of the name "Brazil". ;)
Peter
Not any non-null memory address -- only one that points into an object. As there is no object whose address is the null pointer, the dereference is still undefined. And the compiler knows that.
Another way of looking at it is that tun->sk is equivalent to (*tun).sk, which is even more clearly undefined in C.
Peter
No. Technically, if tun is null, dereferencing it in the expression tun->sk invokes undefined behaviour -- not implementation-defined behaviour. It is perfectly valid to remove the test, because no strictly conforming code could tell the difference -- the game is already over once you've dereferenced a null pointer. This is a kernel bug (and not even, as Brad Spengler appears to be claiming, a new class of kernel bug); it's not a GCC bug.
But as other posters have said, it would indeed be a good security feature for GCC to warn when it does this.
Peter
It's a bit of a pain to explain why Firefox is the same thing as Ice Weasel.
"Because the Mozilla people have done something insane, egotistical, and counter-productive." There, that wasn't very painful.
As you imply, the reason that anyone who forks Firefox should be able to call the binaries their project produces firefox is the same reason that anyone who forks ls should be able to call the binary their project produces ls. Anything else just causes user confusion. If you want to have a trademark because you think you're so darn good that anyone else's version of your code just won't be the same, trademark your organisation name, not your project name. FSF Emacs vs XEmacs, FSF Glibc vs eglibc, coreutils ls vs BSD ls: there's no ambiguity in any of those cases.
By trademarking the name of the product, and imposing restrictions on uses of that trademark which affect people carrying out the normal processes of open-source natural selection, the Mozilla people have placed their own personal egos above the quality of the user experience. That's the sort of behaviour that open-source more usually comes as a blessed relief from.
That such restrictions on trademarked product names are allegedly compatible with open-source licences should be viewed as a bug in those licences, and Debian are absolutely right to call the Mozilla people on not being DFSG-free. If you want to pinpoint the moment they lost their way, it was when they trademarked "Mozilla" and named their foundation after it, and changed the mozilla tree so that it no longer built a binary called mozilla. If when they realised their "mistake" they'd changed the foundation name not the binary name, there'd be the Seamonkey Foundation's mozilla versus everyone else's mozilla, which would be perfectly straightforward, and they'd have generated much less ill will.
Peter
That's exactly the sort of dry wit their writers use.
My favourite The Economist moment:
http://www.avclub.com/articles/february-1-2006,1713/ (final letter)
http://www.avclub.com/articles/february-15-2006,1716/ (final letter)
Links maybe NSFW.
Peter
The mass market wants tick boxes, and customers wanted P4S. If you didn't have P4S, you didn't sell. It's sad and believe me it's true.
Right, it wouldn't have been so bad if the customers actually did want Plays-For-Sure. In fact, they just thought they wanted it -- or worse, perhaps we just thought they thought they wanted it.
Here is a story about Plays-For-Sure. The Rio Carbon was in some ways the poster child for Plays-For-Sure, and for Janus DRM: it was one of the players which Gates himself waved around at the launch event. I don't know how many we sold, but it was a lot. One day in late 2005, Microsoft accidentally revoked the Rio Carbon Janus licence. Or, rather, apparently, they rolled out a new version of the software in the Redmond DRM servers, which made WMP erroneously think that the Carbon licence had been revoked. Either way the effect was the same: for about six weeks until they pushed out a WMP hotfix, nobody anywhere in the world could transfer Plays-For-Sure protected content to their Rio Carbons. And during this six-week period, exactly five users noticed, one of whom was a former Rio employee. That tells you all you need to know about the extent to which consumers actually used or liked Plays-For-Sure.
What saddens me most is the thought of all the cool stuff that we could have implemented if we hadn't been wasting our time doing Plays-For-Sure.
Peter
I turned a corner and swear I saw him sitting there. I even said involuntarily "Hi, Prince..."
Stories like this make me wonder whether we actually hallucinate the presence of cats, maybe even people, all the time, and it's only when it happens after the cat has passed away that we think twice about such events and realise that they must have been hallucinations...
Peter
I'm no RAID expert, but surely the 10^-14 bit error rate the guy is talking about is the rate of previously undiscovered errors? In which case, those errors won't have been found by a bad-sector sweep, nifty though that feature is for advance warning of other problems. His point is that one error in 10^14 bits, though it doesn't sound a lot, is actually one error every time you read 12TB of previously-working data. Which is what happens during RAID5 disk rebuild.
Peter
Notice how Microsoft patents, for example, are owned by Microsoft Corporation, not by the individual coders who came up with whatever algorithm/mechanism/whatever the company is trying to patent.
They're owned by Microsoft, but (AFAIK) the original inventor is still listed by name. When I was in this situation, that was the part that most rankled: that it was 100% the company's idea to file a patent for this stupidly broad and obvious idea, but that my own name would end up on the paperwork. So if this is the case for you too, perhaps you could try and persuade your boss, or someone else, that the conversations you had with them while developing the idea actually mean that they are the real inventor, and should have their name on the patent instead of yours.
FWIW the eventual outcome in my case was that the (UK) patent office rejected the patent, citing as prior art something so left-field that connecting it to the patent application seemed to me much more of an intellectual leap, than coming up with the idea we were trying to patent in the first place. Or, in other words, the company spend thousands of pounds on absolutely nothing and learned not to do that again. Which is a good outcome.
Peter
Without developer buy-in, whatever coding standards you come up with will be useless. IOW, ask your developers to create the standard together.
If you do this, at least filter it past someone who's a language expert before casting it in stone. I once worked somewhere where the official coding style for C demanded that structs were declared like this: "typedef struct _Foo { ... } Foo_t". Either no-one knew, or no-one cared, that names starting with underscore are reserved to the standard library implementor, and that names ending with "_t" are reserved to Posix.
As it turned out, namespace pollution ended up not being among this company's biggest technical problems, but it did make knowledgeable developers feel that their professionalism was being wasted.
Peter
Nothing wrong with reading CS Lewis provided you go on to read Philip Pullman's His Dark Materials for balance
Narnia : Pullman : Bromeliad :: thesis : antithesis : synthesis
Peter
Interestingly, the Belgium joke was added to the American edition of Life, the Universe and Everything. In the original British edition the Rory was an award for the most gratuitous use of the word "fuck" in a serious screenplay.
Yes, but the Belgium joke actually predates that: it was in the second radio series, from which Life, The Universe And Everything was very loosely adapted. (Zaphod says it when about to fall out of the Nutrimatic cup.)
Peter
This already is taught, at least in the UK.
Right, I first learned about this from my GCSE Chemistry teacher in about 1986. He'd been in North Africa in the war, where supply convoys could easily be a couple of miles of a single line of traffic. Each jeep set off when it saw the one in front move, which meant that the ones at the back had to go hell-for-leather to catch up, only to realise that the ones at the front weren't going all that fast. There were regular ~100-jeep pile-ups until they instituted a system where everyone starts their engine and raises their hand when the driver in front does, then drops their hand and moves off when he does that -- which can be seen from a much greater distance along the line.
Peter
Perhaps tomorrow's embedded developers are programming today's desktops.
The desktop machine I learned to program on was an Acorn RiscPC. Later in life, I helped write the embedded firmware in the Rio Karma portable MP3 player. Rio Karma had two 90MHz ARM CPUs, 16Mbytes of RAM, and 20Gbytes of disk. That would have been one kick-ass RiscPC. If anything, programming and optimisation techniques learned on late-80s and early-90s desktops are too "embedded" for a lot of today's embedded programming.
And to those advocating hiring EE graduates for embedded programming: unless your device isn't far north of a toaster on the embeddedness scale, please also hire people with broader or higher-level software expertise for system design and architecture. It's not the same skill as squeezing one more instruction out of a loop, you find people with one skill and not the other, and any medium- or large-scale software project needs both skills (whether in the same person, or through good collaboration).
People go on about the spectrum of computing, software/assembler/logic/gates/transistors; what some don't realise is that there's a spectrum even within software. Some really good, tight, expert coders just can't see the bigger picture. I've seen medium-scale software architected by the toaster contingent: it wasn't pretty.
Peter
That calls into question how the duplicate was made.
Yes, exactly. I'm not questioning whether your friends heard something, I'm just expressing doubt that what they heard was clock jitter. It seems more likely that the duplicate was marginal in some way, resulting in the decoded data being different in the digital domain as well as the analog. (Most audio CD players, even ones from back in the day, can interpolate to produce fictional samples where the real sample can't be read due to bit errors. The results are -- listenable, but clearly not absolutely right.)
Peter
Turned out they could hear the difference between a master CD and a copy of the CD. The difference? Clock jitter. Yes, they could hear the effects of clock jitter.
If they can repeat this feat under laboratory conditions, it would be big news. Even a one-bit FIFO destroys any effect, measurable or audible, that clock jitter on the source CD has on components downstream of the FIFO -- but audio CD has much deeper than one-bit FIFOs to implement the error-correction. Neither the DAC (if present) or digital output (if not) of an audio CD player is directly clocked from the CD pits.
Peter
Not to rain on your parade, but the linked article does rather make the opposite point from what you're saying.
Analysts say that, and a journalist has linked it to HMV's falling profits. But look at what the article quotes Fopp themselves as saying: Fopp was "profitable and well regarded but had failed to gain support from stakeholders and suppliers"; they're seeking "reinstatement of the suppliers' licence to sell". Fopp weren't killed by Amazon or by Bittorrent, they were killed by the labels and distributors. It sounds rather as if the music industry, perhaps supported by more traditional supplicants such as HMV, objected to Fopp's policy of selling what people want to buy, at prices they're prepared to pay.
Peter (no connection to Fopp except repeat satisfied customer)
The God's Script
Peter