Good UIs should be designed to work with a single mouse button, because that means that they'll also work well with a touchscreen. There's nothing wrong with making some things faster with the right mouse button, which is how most Mac applications work. The right mouse button for the context menu was inherited from NeXTSTEP, where the 'normal' menu was a floating version and you could cause a copy of it to pop up wherever the mouse was with the right mouse button (RISC OS took this further and didn't have any kind of menu bar, using the middle mouse button to produce the menu on demand. Using RISC OS with a touchscreen or pen tablet was... interesting, and it only just counted as discoverable because the machines shipped with a mouse with the buttons labelled).
When I'm reading a document, I'll do two-fingered scrolling on the trackpad to navigate. I only use home/end and page up/down when I'm typing, to navigate within the document, and then I already have both of my hands on the keyboard. The function key can be pressed with the knuckle of the little finger of the left hand, so is pretty easy to hit.
Windows-R brings up the run dialog, which will autocomplete program names and used to be the fastest way of launching programs on Windows (it's well over 10 years since I last regularly used Windows, so I don't know if this has changed). Windows-D showed the desktop and Windows-F the system find dialog. All of these were pretty useful, but the key was still quite under-utilised.
Control and alternate already have well-defined meanings. Control is for entering control characters, alternate is for entering alternate characters. OS X uses both. UNIX keyboards used to come with a meta key, but this fell out of use as software was written for PCs without such a key. On OS X, the usage of the command key is inherited from classic MacOS: It's the modifier that you hold for commands. This means that the OS X terminal is the only graphical terminal that I've come across that doesn't suck for copy and paste. On OS X, every single program including the terminal uses command-C for copy and command-V for paste. The terminal is therefore free to use control-C for sending the character that they terminal recognises for SIGINT. Windows overloaded the alternate key for opening menus, which meant that it is no longer a convenient key if you need to enter non-ASCII characters (for example, a Euro symbol or a letter with an accent, which are both easy to enter on a Mac). Most desktop environments for Linux inherited a load of bad UI design from Windows before adding their own mistakes.
The difference between persistent and temporary storage is important. Being able to have 128GB of RAM in a laptop that consumes no power when not being read or written would be a huge win (one of the reasons phones have limited RAM is that DRAM draws power all the time) would be very nice.
Oh, I agree - you'd have added a lot of hardware complexity and probably more than you'd be able to fit if you wanted to keep 7 of them in the thermal envelope of the Cell.
An increasing number of phones now come with mini-HDMI (or some kind of external HDMI adaptor). If you travel a lot, then being able to hook it up to a hotel room TV and watch a film can be quite nice.
An alarming number of those hold for Chromium and they all stem from one core issue: Google developers do not understand how to design APIs. A lot of the bundled projects could be entirely separate repositories and shipped as shared libraries if they did, but gratuitous API churn means that they have to keep copies of things like v8 and Skia for Chrome and build the whole thing at once. It's fine to do the aggregate build thing if you want LTO, but it should be a performance optimisation, not a requirement of the software engineering workflow.
It depends a lot on the codebase. Codebases tend to accumulate cruft. Having people refactor them because their requirements are different to yours can help, as can having a project developed without key product ship dates as the driving force. The bigger barrier is culture though. It's really hard to have a group of developers that have been working on a project for 10 years in private move to developing in public. In the list, he actually gives different numbers of fail points, more for projects that were proprietary for longer than they were open, which makes a lot more sense than the summary in the 'article'.
The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.
I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.
AJAX provides a mechanism for delivering the XML. How many popular web apps can you name that completely separate the back end and the front end and provide documentation for users to talk directly to the back end and substitute their own UI or amalgamate the data with that from other services? Of those, how many provide the data in a self-documenting form?
There's no problem with the decoder. The A8 is an older chip. The A7 is an updated version of the A8 (smaller, more power efficient due to various tweaks and extended to support a newer version of the instruction set so that it can be used in big.LITTLE configurations with the A15. Oh, and with SMP support, which the A8 lacked, though the A9 had). The A8 is not faster than the A7.
As I was saying: If your kids are immunocompromised, they have a lot more to worry about than measles. That is, there are many other diseases they have to worry about besides the few we can vaccinate against.
Why do you keep talking about immunocompromised people? The measles vaccine, for example, only works in about 95% of cases, the other people are not immunised. They have no other autoimmune issues and, unless exposed to the measles virus, will have no issues.
Almost everybody in "the entire population" who is vaccinated is protected by the vaccine and hence not "vulnerable". So "the entire population" doesn't become more vulnerable.
If immunity drops below about 93% for measles, then the population no longer benefits from herd immunity. This means that anyone who is not immune (including those 5% who were vaccinated but didn't receive the benefit) is at a much higher risk of being infected. It also means more infections, which increases the probability of the disease mutating, which affects everyone. People who are infected then have compromised immune systems and so are likely to suffer from other infections, which can then spread to the rest of the population.
Most vaccines are not 100% effective. You need a certain percentage of the population to be immune for herd immunity to mean that they have little chance of contracting the disease (and, if they do, a good chance of being an isolated statistic rather than the centre of an outbreak). It only takes a few percent opting out of the vaccine to eliminate the herd immunity and make the entire population more vulnerable.
When people talk about an n-bit CPU, they're conflating a lot of things:
Register size (address and data register size on archs that have separate ones).
Largest ALU op size
Virtual address size
Physical address size
Bus data lane size
Bus address lane size
It's very rare to find a processor where all of these are the same. Intel tried marketing the Pentium as a 64-bit chip for a while because it had 64-bit ALU ops. Most '64-bit' processors actually have something like a 48-bit virtual and 40-bit physical address space, but 64-bit registers and ALU ops (and some have 128-bit and 256-bit vector registers and ALU ops). The Pentium Pro with PAE had a 36-bit physical but 32-bit virtual address space, so you only got 4GB of address space per process, but multiple processes could use more than 4GB between them. This is the opposite way around to what you want for an OS, where you want to be able to map all of physical memory into your kernel's virtual address space and is one of the reasons that PAE kernels came with a performance hit.
Videogame programmer here. It wasn't really a compiler optimization issue. There's no compiler on the planet that can perform high-level optimizations like that.
Compiler engineer here. The vectorisation for the Cell wasn't the hard part, it was the data management. Autovectorisation and even autoparallelisation are done by some compilers (the Sun compiler suite was doing both before the Cell was introduced), and can be aided by OpenMP or similar annotations. If the Cell SPUs had been cache-coherent and had direct access to DRAM, then there's a good chance that a bit of investment in the compiler would have given a big speedup. The problem of deciding when to DMA data to and from the SPUs and where you need to add explicit synchronisation into the PPU was much, much harder. I've worked on a related problem in the context of automatic offload to GPUs and it turns out to be non-computable in most nontrivial cases (it depends heavily on accurate alias analysis).
I think you have some of those the wrong way around: The A7 is about 20% faster than the A8 (it's an A8 that's had the decoder replaced with one that's compatible with the A15 and been left with the engineering group with the most OCD to optimise for a year or so).
MIPS and PowerPC are still huge in embedded. MIPS is used on a huge number of cheap routers and a lot of these are in dire need of a better OS than they ship with (and many of them ship with a hacked-up Linux). PowerPC is mostly big in automotive, but IBM still sells machines and is willing to keep funding a lot of the software support. The same goes for S/390: a big part of IBM's sales pitch there is that you can spin up Linux VMs on it easily and run the OS that you're used to. SPARC these days basically means Oracle appliances. You don't buy a SPARC machine if you want to run Linux, you buy one if you want to do the vertical integration thing with Oracle (i.e. Oracle arranges you vertically with your head downwards and shakes until all of the money is integrated with their wallet).
Someone needs to develop the software. The difference between open source and proprietary software is that open source software is developed by and for people who want to use it, proprietary software is developed by people who want to sell it. Successful projects are ones where the people who want to use it want to use it enough to fund development.
We had a couple of those. You should have tried NetBSD. For a very long time, Linux had particularly bad handling of the SPARC TLB and NetBSD was faster to the extent that it was noticeable by the user in the GUI.
apart from the terrible quality of the CG3 driver in Xfree, which would lock the entire machine up solid after about 30 minutes of use
When was these? Even after they stopped being useful as stand-alone machines, we used them as dumb X servers and easily had a few weeks of XFree86 uptime.
Okay, let's remove the coercion then and have a proper libertarian solution. No one has to get vaccinated, but anyone who is not vaccinated is liable for and harm done by anyone that they infected with a disease, including joint liability for all outbreaks of that disease where the vaccinated number dropped below the number responsible for herd immunity.
By all means, go ahead and defend your right to kill people as a result of your negligence.
No idea. Open source FPGA toolchains are definitely interesting, mostly because Altera and Xilinx compete on who can produce the worst software. Having a single toolchain that could target both (which this project is still a long way away from) would be very useful. Unfortunately, high-end FPGAs vary a lot both in the core logic block structure and the number and layout of the fixed-function macroblocks that are available.
Slashdot Mirror
Good UIs should be designed to work with a single mouse button, because that means that they'll also work well with a touchscreen. There's nothing wrong with making some things faster with the right mouse button, which is how most Mac applications work. The right mouse button for the context menu was inherited from NeXTSTEP, where the 'normal' menu was a floating version and you could cause a copy of it to pop up wherever the mouse was with the right mouse button (RISC OS took this further and didn't have any kind of menu bar, using the middle mouse button to produce the menu on demand. Using RISC OS with a touchscreen or pen tablet was... interesting, and it only just counted as discoverable because the machines shipped with a mouse with the buttons labelled).
When I'm reading a document, I'll do two-fingered scrolling on the trackpad to navigate. I only use home/end and page up/down when I'm typing, to navigate within the document, and then I already have both of my hands on the keyboard. The function key can be pressed with the knuckle of the little finger of the left hand, so is pretty easy to hit.
Windows-R brings up the run dialog, which will autocomplete program names and used to be the fastest way of launching programs on Windows (it's well over 10 years since I last regularly used Windows, so I don't know if this has changed). Windows-D showed the desktop and Windows-F the system find dialog. All of these were pretty useful, but the key was still quite under-utilised.
Control and alternate already have well-defined meanings. Control is for entering control characters, alternate is for entering alternate characters. OS X uses both. UNIX keyboards used to come with a meta key, but this fell out of use as software was written for PCs without such a key. On OS X, the usage of the command key is inherited from classic MacOS: It's the modifier that you hold for commands. This means that the OS X terminal is the only graphical terminal that I've come across that doesn't suck for copy and paste. On OS X, every single program including the terminal uses command-C for copy and command-V for paste. The terminal is therefore free to use control-C for sending the character that they terminal recognises for SIGINT. Windows overloaded the alternate key for opening menus, which meant that it is no longer a convenient key if you need to enter non-ASCII characters (for example, a Euro symbol or a letter with an accent, which are both easy to enter on a Mac). Most desktop environments for Linux inherited a load of bad UI design from Windows before adding their own mistakes.
The difference between persistent and temporary storage is important. Being able to have 128GB of RAM in a laptop that consumes no power when not being read or written would be a huge win (one of the reasons phones have limited RAM is that DRAM draws power all the time) would be very nice.
But that's a pretty big "if" there
Oh, I agree - you'd have added a lot of hardware complexity and probably more than you'd be able to fit if you wanted to keep 7 of them in the thermal envelope of the Cell.
It's mostly opinion, formed from watching Google's interaction with standards processes and browser development communities.
If people can't write good commit messages, what makes you think that they'll write good commit messages in a separate document?
An increasing number of phones now come with mini-HDMI (or some kind of external HDMI adaptor). If you travel a lot, then being able to hook it up to a hotel room TV and watch a film can be quite nice.
On the plus side, it does have more space than a Nomad.
An alarming number of those hold for Chromium and they all stem from one core issue: Google developers do not understand how to design APIs. A lot of the bundled projects could be entirely separate repositories and shipped as shared libraries if they did, but gratuitous API churn means that they have to keep copies of things like v8 and Skia for Chrome and build the whole thing at once. It's fine to do the aggregate build thing if you want LTO, but it should be a performance optimisation, not a requirement of the software engineering workflow.
It depends a lot on the codebase. Codebases tend to accumulate cruft. Having people refactor them because their requirements are different to yours can help, as can having a project developed without key product ship dates as the driving force. The bigger barrier is culture though. It's really hard to have a group of developers that have been working on a project for 10 years in private move to developing in public. In the list, he actually gives different numbers of fail points, more for projects that were proprietary for longer than they were open, which makes a lot more sense than the summary in the 'article'.
The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.
I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.
As for "web page", AJAX apps do exactly this
AJAX provides a mechanism for delivering the XML. How many popular web apps can you name that completely separate the back end and the front end and provide documentation for users to talk directly to the back end and substitute their own UI or amalgamate the data with that from other services? Of those, how many provide the data in a self-documenting form?
There's no problem with the decoder. The A8 is an older chip. The A7 is an updated version of the A8 (smaller, more power efficient due to various tweaks and extended to support a newer version of the instruction set so that it can be used in big.LITTLE configurations with the A15. Oh, and with SMP support, which the A8 lacked, though the A9 had). The A8 is not faster than the A7.
As I was saying: If your kids are immunocompromised, they have a lot more to worry about than measles. That is, there are many other diseases they have to worry about besides the few we can vaccinate against.
Why do you keep talking about immunocompromised people? The measles vaccine, for example, only works in about 95% of cases, the other people are not immunised. They have no other autoimmune issues and, unless exposed to the measles virus, will have no issues.
Almost everybody in "the entire population" who is vaccinated is protected by the vaccine and hence not "vulnerable". So "the entire population" doesn't become more vulnerable.
If immunity drops below about 93% for measles, then the population no longer benefits from herd immunity. This means that anyone who is not immune (including those 5% who were vaccinated but didn't receive the benefit) is at a much higher risk of being infected. It also means more infections, which increases the probability of the disease mutating, which affects everyone. People who are infected then have compromised immune systems and so are likely to suffer from other infections, which can then spread to the rest of the population.
Right, because the only place that people interact is at school.
Most vaccines are not 100% effective. You need a certain percentage of the population to be immune for herd immunity to mean that they have little chance of contracting the disease (and, if they do, a good chance of being an isolated statistic rather than the centre of an outbreak). It only takes a few percent opting out of the vaccine to eliminate the herd immunity and make the entire population more vulnerable.
It's very rare to find a processor where all of these are the same. Intel tried marketing the Pentium as a 64-bit chip for a while because it had 64-bit ALU ops. Most '64-bit' processors actually have something like a 48-bit virtual and 40-bit physical address space, but 64-bit registers and ALU ops (and some have 128-bit and 256-bit vector registers and ALU ops). The Pentium Pro with PAE had a 36-bit physical but 32-bit virtual address space, so you only got 4GB of address space per process, but multiple processes could use more than 4GB between them. This is the opposite way around to what you want for an OS, where you want to be able to map all of physical memory into your kernel's virtual address space and is one of the reasons that PAE kernels came with a performance hit.
Videogame programmer here. It wasn't really a compiler optimization issue. There's no compiler on the planet that can perform high-level optimizations like that.
Compiler engineer here. The vectorisation for the Cell wasn't the hard part, it was the data management. Autovectorisation and even autoparallelisation are done by some compilers (the Sun compiler suite was doing both before the Cell was introduced), and can be aided by OpenMP or similar annotations. If the Cell SPUs had been cache-coherent and had direct access to DRAM, then there's a good chance that a bit of investment in the compiler would have given a big speedup. The problem of deciding when to DMA data to and from the SPUs and where you need to add explicit synchronisation into the PPU was much, much harder. I've worked on a related problem in the context of automatic offload to GPUs and it turns out to be non-computable in most nontrivial cases (it depends heavily on accurate alias analysis).
I think you have some of those the wrong way around: The A7 is about 20% faster than the A8 (it's an A8 that's had the decoder replaced with one that's compatible with the A15 and been left with the engineering group with the most OCD to optimise for a year or so).
MIPS and PowerPC are still huge in embedded. MIPS is used on a huge number of cheap routers and a lot of these are in dire need of a better OS than they ship with (and many of them ship with a hacked-up Linux). PowerPC is mostly big in automotive, but IBM still sells machines and is willing to keep funding a lot of the software support. The same goes for S/390: a big part of IBM's sales pitch there is that you can spin up Linux VMs on it easily and run the OS that you're used to. SPARC these days basically means Oracle appliances. You don't buy a SPARC machine if you want to run Linux, you buy one if you want to do the vertical integration thing with Oracle (i.e. Oracle arranges you vertically with your head downwards and shakes until all of the money is integrated with their wallet).
Someone needs to develop the software. The difference between open source and proprietary software is that open source software is developed by and for people who want to use it, proprietary software is developed by people who want to sell it. Successful projects are ones where the people who want to use it want to use it enough to fund development.
Debian hamm sucked quite a bit less than SunOS
We had a couple of those. You should have tried NetBSD. For a very long time, Linux had particularly bad handling of the SPARC TLB and NetBSD was faster to the extent that it was noticeable by the user in the GUI.
apart from the terrible quality of the CG3 driver in Xfree, which would lock the entire machine up solid after about 30 minutes of use
When was these? Even after they stopped being useful as stand-alone machines, we used them as dumb X servers and easily had a few weeks of XFree86 uptime.
Okay, let's remove the coercion then and have a proper libertarian solution. No one has to get vaccinated, but anyone who is not vaccinated is liable for and harm done by anyone that they infected with a disease, including joint liability for all outbreaks of that disease where the vaccinated number dropped below the number responsible for herd immunity.
By all means, go ahead and defend your right to kill people as a result of your negligence.
No idea. Open source FPGA toolchains are definitely interesting, mostly because Altera and Xilinx compete on who can produce the worst software. Having a single toolchain that could target both (which this project is still a long way away from) would be very useful. Unfortunately, high-end FPGAs vary a lot both in the core logic block structure and the number and layout of the fixed-function macroblocks that are available.