Wouldn't it be just a matter of re-compiling your code though?
Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.
I love MIPS and, that is the case in large part, because of its current instruction set. It seems like a bad idea to mess with the current instruction set and break backward compatibility. Why did they decide to do that?
Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.
There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.
For building big C++ projects, as long as the disk (yay SSDs!) can keep up, you can throw as many cores as you can get at the compile step and get a speedup, then sit dependent on single-thread performance for the linking. I got a huge speedup going from a Core 2 Duo to a Sandy Bridge quad i7, then another noticeable speedup going to a Haswell i7 in my laptop. The laptop is now sufficiently fast that I do a lot more locally - previously I'd mostly work on a remote server with 32 cores, 256GB of RAM (and a 3TB mirrored ZFS array with a 512GB SSD for ZIL and L2ARC), but now the laptop is only about a factor of 2 slower in terms of build times, so for developing individual components (e.g. LLVM+Clang) I'll use the laptop and only build the complete system on the server.
There are several nice features of a landline, but they can't (in the UK, at least) compete on price. The line rental alone for a landline costs more than I spend on calls on my mobile (pre-pay, no contract, no monthly fees). Calls from my mobile are 3p/minute, a landline is £16/month. I'd need to spend almost 9 hours on the phone each month before I spent as much on my mobile as a landline would cost me before I even made any calls. And then, for the kicker, the calls from the landline cost 9p/min (+15p setup) for calls to other landlines or 12p/min (+15p setup) for calls to mobiles. There's no possible justification for calls from the landline costing 3-4 times as much as calls from the mobile on top of the extortionate line rental. If I wanted to pay BT even more, for another £3 I could get free evening and weekend calls to landlines, but calls to mobiles would still be the same price. For £7.50 on top of the line rental, I'd get free calls to landlines, and calls to mobiles would only be twice the cost of my mobile. Almost everyone I call has a mobile though, so in exchange for paying BT an amount equivalent to about 12 hours of calls on my mobile per month, I could then pay double per minute what I pay for calls on my mobile with no line rental.
Lighting (the Mozilla calendar app) is also pretty nice. Rust is gaining a lot of interest as a systems programming language, although not so much in the application space.
It has significantly reduced my ability to customize the user interface of Firefox to suit my needs.
Again, hand waving without specifics. The most noticeable change for me was that they button to customise the UI is now on the toolbar by default, rather than hidden away somewhere. What can you no longer customise that you could previously?
I really don't understand this complaint. The UI changes were relatively small, and one of the biggest ones was making the 'customize UI' button more prominent in the new versions.
I switched to Firefox on Android recently because Chrome for Android has the same handicapped cookie management policy as the older Android Browser, but Firefox lets me run the self-destructing cookies plugin, which does exactly what I've wished for the last 15 years all browsers would do by default.
No, it's developed in the open, but it's really hard to get changes pushed upstream. We have a bunch of patches for the FreeBSD support and to improve sandboxing, and it looks like it will end up taking 2-3 years to get them all upstreamed. Meanwhile, the code follows the traditional Google development model of gratuitously refactoring things (are Google people paid by number of lines of code changed?), so it's a lot of effort just to keep the patches up to date.
Building schools after you've been seen to come in and overthrow their government doesn't buy you nearly as much goodwill as building schools after you've just helped them overthrow a foreign invader and then removed your military presence from the country.
Arming Afghanistan wasn't the problem. Arming them in secret (so most of the population had no idea that the USA was spending half a billion dollars a year on helping them fight the USSR and felt abandoned) and then cutting off the money as soon as the USSR pulled out and leaving the country a mess, rather than helping to rebuild schools and so on was the problem.
And for good measure, Ukraine should "sell" its ownership in the Ukrainian section of the gas pipeline to a Nato country and then shut off the flow of gas.
Cutting off the flow of gas would hurt Europe a lot more than it would hurt Russia at this point. Entering the winter with your largest gas supplier no longer providing you with the gas that you use for heating would suck. And as gas is fungible, it doesn't matter to Russia if we stop buying it from them, unless everyone else stops buying it from them - if China doesn't join in with the boycott then it just means that they'll be buying more has from Russia because the price of everyone else's gas will go up.
I'm not that old, but I work with quite a lot of people who are older than you at various big companies. They're all exceedingly competent. I suspect that's part of the problem for the grandparent: the older you are, the greater the expectations. If you're as competent at 45 as someone else at 25, then people start to wonder how you've managed to work for 20 without gaining more insight. If you hire a competent 25 year old, then there's a good chance that they'll mature and improve over the next 5-10 years. If you hire someone who has only achieved the same level of competence by the time that they're 45, then they don't look like such a good investment.
It is possible, but for good performance it needs hardware support. We've implemented hardware-enforced bounds checking for C code using our processor. If you only care about accidental bugs and not about a malicious attacker, and don't use threads (or are happy to bound every pointer store with a transactional region), and don't mind that the semantics of C are subtly broken in the kinds of permitted pointer operations, then Intel's Memory Protection Extensions will do the same thing.
The OpenBSD philosophy says that the difference between a bug and a vulnerability is the intelligence of the attacker. There are lots of categories of bugs (null pointer dereferences, integer overflows) that were thought to be unexploitable, right up until someone exploited them. It's the same as with cryptosystems: the fact that you can't break your encryption algorithm doesn't mean that it's secure.
Your laptop has to be on the same network as your backup machine, but even backing up my laptop over WiFi only takes a couple hours for an incremental backup. I don't have to leave it doing nothing, I just need to leave it on. If I haven't backed up for a while, I might leave it doing the backup overnight, but most of the time I run the backup while I'm working.
I bought 3 2TB disks just before the flood. About a month ago, they finally became cheaper than I paid. I'd been planning on swapping them out for 4TB disks after 2-3 years, but the 4TB ones are still 50% more than I paid for the 2TB disks. At this rate, 4TB flash will hit the £50 mark before 4TB hard disks...
The difference in cost between tapes and disks hasn't changed much, but the difference in cost of the tape drives to disk drives has changed hugely. You used to be able to get a tape and a drive for only a little bit more than the cost of the disk it would back up. It made sense to use tapes for backups then, because you could afford one tape for the same cost as a backup disk and add new tapes for very little money. Now, if you buy a disk at the sweet spot for price, the tape drive that can back it up to a single tape will cost you about an order of magnitude more than the disk drive. At that point, unless you want a lot more than 10 backups per disk, it isn't worth it.
That's not necessarily true. You can get the same amount of space in a smaller number of tracks around the edge of the disk, so the horizontal movement for the largest seek is going to be smaller. Seek times on mechanical disks are based on three factors. The first two are related: the time it takes to move the head between tracks (proportional to its distance) and the time it takes for the head to settle and be able to be lowered again (dependent on its speed). The third is the time it takes for the correct sector on the track to spin under the head. In the middle, you have fewer sectors per track, so you need to move the head more often (this is where the upper bound on seek times comes from).
It's probably the ultra-restricted version of Jazelle that is part of ARMv7 - it supports the branch to Jazelle mode instruction, but throws a trap when it is encountered so that it can be emulated by a JIT compiler.
We've actually paid more tax per head, and received less back per head, than England for every one of the last 110 years, which is as far back as the available data goes
A big citation needed there. The last time I looked at the data was in 1998, but back then English tax payers were paying an average of around £100 each for the upkeep of Scotland, if you didn't include the north sea gas revenues.
The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:
Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.
There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.
There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).
The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.
XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.
None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).
If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.
It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.
There's nothing intrinsically good about the UNIX mindset. For example, UNIX originally put globing in the shell as a work around for not having shared libraries and claimed it was a feature (which led to all sorts of problems - for example */*/* can overflow the command-line argument length limit, whereas a system that had put globing in a shared library would have lazily expanded it in the called program). The problem with the systemd developers is not that they lack the UNIX mindset, it's that they produce utter crap and somehow are able to market it successfully.
Slashdot Mirror
Wouldn't it be just a matter of re-compiling your code though?
Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.
I love MIPS and, that is the case in large part, because of its current instruction set. It seems like a bad idea to mess with the current instruction set and break backward compatibility. Why did they decide to do that?
Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.
There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.
For building big C++ projects, as long as the disk (yay SSDs!) can keep up, you can throw as many cores as you can get at the compile step and get a speedup, then sit dependent on single-thread performance for the linking. I got a huge speedup going from a Core 2 Duo to a Sandy Bridge quad i7, then another noticeable speedup going to a Haswell i7 in my laptop. The laptop is now sufficiently fast that I do a lot more locally - previously I'd mostly work on a remote server with 32 cores, 256GB of RAM (and a 3TB mirrored ZFS array with a 512GB SSD for ZIL and L2ARC), but now the laptop is only about a factor of 2 slower in terms of build times, so for developing individual components (e.g. LLVM+Clang) I'll use the laptop and only build the complete system on the server.
There are several nice features of a landline, but they can't (in the UK, at least) compete on price. The line rental alone for a landline costs more than I spend on calls on my mobile (pre-pay, no contract, no monthly fees). Calls from my mobile are 3p/minute, a landline is £16/month. I'd need to spend almost 9 hours on the phone each month before I spent as much on my mobile as a landline would cost me before I even made any calls. And then, for the kicker, the calls from the landline cost 9p/min (+15p setup) for calls to other landlines or 12p/min (+15p setup) for calls to mobiles. There's no possible justification for calls from the landline costing 3-4 times as much as calls from the mobile on top of the extortionate line rental. If I wanted to pay BT even more, for another £3 I could get free evening and weekend calls to landlines, but calls to mobiles would still be the same price. For £7.50 on top of the line rental, I'd get free calls to landlines, and calls to mobiles would only be twice the cost of my mobile. Almost everyone I call has a mobile though, so in exchange for paying BT an amount equivalent to about 12 hours of calls on my mobile per month, I could then pay double per minute what I pay for calls on my mobile with no line rental.
I enjoyed that article, but it's worth noting that vi actually is standard.
Lighting (the Mozilla calendar app) is also pretty nice. Rust is gaining a lot of interest as a systems programming language, although not so much in the application space.
It has significantly reduced my ability to customize the user interface of Firefox to suit my needs.
Again, hand waving without specifics. The most noticeable change for me was that they button to customise the UI is now on the toolbar by default, rather than hidden away somewhere. What can you no longer customise that you could previously?
The problem is that it's a dumbed-down UI design
I really don't understand this complaint. The UI changes were relatively small, and one of the biggest ones was making the 'customize UI' button more prominent in the new versions.
I switched to Firefox on Android recently because Chrome for Android has the same handicapped cookie management policy as the older Android Browser, but Firefox lets me run the self-destructing cookies plugin, which does exactly what I've wished for the last 15 years all browsers would do by default.
No, it's developed in the open, but it's really hard to get changes pushed upstream. We have a bunch of patches for the FreeBSD support and to improve sandboxing, and it looks like it will end up taking 2-3 years to get them all upstreamed. Meanwhile, the code follows the traditional Google development model of gratuitously refactoring things (are Google people paid by number of lines of code changed?), so it's a lot of effort just to keep the patches up to date.
Building schools after you've been seen to come in and overthrow their government doesn't buy you nearly as much goodwill as building schools after you've just helped them overthrow a foreign invader and then removed your military presence from the country.
Arming Afghanistan wasn't the problem. Arming them in secret (so most of the population had no idea that the USA was spending half a billion dollars a year on helping them fight the USSR and felt abandoned) and then cutting off the money as soon as the USSR pulled out and leaving the country a mess, rather than helping to rebuild schools and so on was the problem.
And for good measure, Ukraine should "sell" its ownership in the Ukrainian section of the gas pipeline to a Nato country and then shut off the flow of gas.
Cutting off the flow of gas would hurt Europe a lot more than it would hurt Russia at this point. Entering the winter with your largest gas supplier no longer providing you with the gas that you use for heating would suck. And as gas is fungible, it doesn't matter to Russia if we stop buying it from them, unless everyone else stops buying it from them - if China doesn't join in with the boycott then it just means that they'll be buying more has from Russia because the price of everyone else's gas will go up.
I'm 45 and recruiters bother me more than ever.
I'm not that old, but I work with quite a lot of people who are older than you at various big companies. They're all exceedingly competent. I suspect that's part of the problem for the grandparent: the older you are, the greater the expectations. If you're as competent at 45 as someone else at 25, then people start to wonder how you've managed to work for 20 without gaining more insight. If you hire a competent 25 year old, then there's a good chance that they'll mature and improve over the next 5-10 years. If you hire someone who has only achieved the same level of competence by the time that they're 45, then they don't look like such a good investment.
What high-level language does not depend on the C standard library and so would be suitable for implementing the C standard library?
It is possible, but for good performance it needs hardware support. We've implemented hardware-enforced bounds checking for C code using our processor. If you only care about accidental bugs and not about a malicious attacker, and don't use threads (or are happy to bound every pointer store with a transactional region), and don't mind that the semantics of C are subtly broken in the kinds of permitted pointer operations, then Intel's Memory Protection Extensions will do the same thing.
The OpenBSD philosophy says that the difference between a bug and a vulnerability is the intelligence of the attacker. There are lots of categories of bugs (null pointer dereferences, integer overflows) that were thought to be unexploitable, right up until someone exploited them. It's the same as with cryptosystems: the fact that you can't break your encryption algorithm doesn't mean that it's secure.
Actually, come to think of it, my first hard drive (40MB!) didn't fail, but my second one (60MB in a laptop) did.
Your laptop has to be on the same network as your backup machine, but even backing up my laptop over WiFi only takes a couple hours for an incremental backup. I don't have to leave it doing nothing, I just need to leave it on. If I haven't backed up for a while, I might leave it doing the backup overnight, but most of the time I run the backup while I'm working.
I bought 3 2TB disks just before the flood. About a month ago, they finally became cheaper than I paid. I'd been planning on swapping them out for 4TB disks after 2-3 years, but the 4TB ones are still 50% more than I paid for the 2TB disks. At this rate, 4TB flash will hit the £50 mark before 4TB hard disks...
The difference in cost between tapes and disks hasn't changed much, but the difference in cost of the tape drives to disk drives has changed hugely. You used to be able to get a tape and a drive for only a little bit more than the cost of the disk it would back up. It made sense to use tapes for backups then, because you could afford one tape for the same cost as a backup disk and add new tapes for very little money. Now, if you buy a disk at the sweet spot for price, the tape drive that can back it up to a single tape will cost you about an order of magnitude more than the disk drive. At that point, unless you want a lot more than 10 backups per disk, it isn't worth it.
That's not necessarily true. You can get the same amount of space in a smaller number of tracks around the edge of the disk, so the horizontal movement for the largest seek is going to be smaller. Seek times on mechanical disks are based on three factors. The first two are related: the time it takes to move the head between tracks (proportional to its distance) and the time it takes for the head to settle and be able to be lowered again (dependent on its speed). The third is the time it takes for the correct sector on the track to spin under the head. In the middle, you have fewer sectors per track, so you need to move the head more often (this is where the upper bound on seek times comes from).
It's probably the ultra-restricted version of Jazelle that is part of ARMv7 - it supports the branch to Jazelle mode instruction, but throws a trap when it is encountered so that it can be emulated by a JIT compiler.
We've actually paid more tax per head, and received less back per head, than England for every one of the last 110 years, which is as far back as the available data goes
A big citation needed there. The last time I looked at the data was in 1998, but back then English tax payers were paying an average of around £100 each for the upkeep of Scotland, if you didn't include the north sea gas revenues.
The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:
Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.
There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.
There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).
The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.
XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.
None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).
If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.
It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.
There's nothing intrinsically good about the UNIX mindset. For example, UNIX originally put globing in the shell as a work around for not having shared libraries and claimed it was a feature (which led to all sorts of problems - for example */*/* can overflow the command-line argument length limit, whereas a system that had put globing in a shared library would have lazily expanded it in the called program). The problem with the systemd developers is not that they lack the UNIX mindset, it's that they produce utter crap and somehow are able to market it successfully.