Your post is so full of errors it hurts to read. The const qualifier refers to the data, not the variable in this context. The following is entirely valid:
const char *post = "first"; post = "second";
The following will have the behaviour that you are claiming:
char *const post = "first"; post = "second";
This will get a compiler error, however consider this version instead:
char *const post = "first"; post[0] = 0;
This will not give a compiler error, but will abort at run time. The type of a string literal is const char * and so it is placed in the constant data section, which may be in ROM on embedded systems and will be mapped read-only (and shared between processes) on other systems. The same problem will happen if you omit the const. The correct way to write this is:
const char *post = "first"; post[0] = 0;
This will give a compiler error on the assignment, because you are attempting to modify constant data. You will also get a compiler warning if you try to implicitly cast to char*, because the code that receives the char* may attempt to modify the data.
Any competent C programmer would use the const only when it's appropriate, to tell the compiler that a symbol isn't a variable
I guess we know exactly where you fit on the C-competence spectrum then...
No, permissions are things like execute, read, write. There are also some flags. For example, you can seal a capability and then you can't use it unless it is unsealed by a special form of jump instruction that can be used to implement protection boundaries. The architecture is being developed at Cambridge as part of a DARPA grant to see what you'd do if you were allowed to change anything about computing to improve security: it's a softcore running on an FPGA, running FreeBSD and (almost - I need the latest round of ISA revisions to be finished before I can make everything work) with an LLVM compiler, so we can change any aspect of the stack, from CPU, kernel, compiler and upwards.
If you read The UNIX Haters' Handbook, it proposes exactly this... in the mid '80s. Back then it wasn't even a novel idea, Lisp and Smalltalk environments did it. AppleScript does more or less this, exposing model objects to scripting. With osascript you can run AppleScript scripts from the command line on OS X.
I'm not a huge fan of the PowerShell syntax, but the concept is definitely one of the rare cases of Microsoft copying good ideas, something I wish more tech companies would do more often.
CHERI. It's an experimental MIPS-derived chip that has 32 256-bit capability registers, which are basically fat pointers containing a base, length, and set of permissions.
You mean intptr_t. ptrdiff_t is the largest size of an object. On segmented architectures, it can be the maximum size of a segment. ptrdiff_t is large enough to hold the result of any defined pointer comparison, but pointer comparisons are only defined (in C) on pointers within the same object.
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
If you are likely to need more than 4GB of RAM, don't compile in X32 mode. Of course, if some of your applications use X32 and some use X64 mode, then you'll need two copies of shared libraries loaded, and one extra copy of glibc is likely to offset all of the benefits of X32 mode unless you are running some very unusually pointer-heavy workloads in the X32 programs.
64 bit architectures give you 64-bit registers and a 64-bit address space (since pointers are, traditionally, integers that fit in registers[1]). On x86, there are a number of other advantages to using the 64-bit long mode: guaranteed SSE so you don't need slow x87 code, more registers, PC-relative addressing (useful for position-independent code) and so on. The cost of using these is that now every pointer is bigger. This has knock-on effects in terms of data cache usage.
The X32 ABI allows you to have all of the benefits of the 64-bit mode except for the larger address space. If you're using under 4GB of memory, then it can, in theory give an improvement in memory and cache usage.
There are two down sides. The first is that, in my testing of C, C++ and Objective-C code, I've found that it's very rare on a 64-bit platform for pointers to account for even 10% of the total memory usage, and usually it's a lot less. This is made worse by the fact that the X64 and X32 ABIs are incompatible, so you may need two copies of the same library in memory if you have code using both.
I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
[1] Not with the architecture I'm currently working with, and I'm spending a lot of time fixing compiler assumptions that this is always the case.
The issue is that a lot of software was written on the assumption that there are 60 seconds in a minute. If something happens at the 61st second of a minute, stuff gets confused. Either it rejects the event, or incorrectly marks the time. Leap seconds are an incredibly expensive idiocy designed to make a few astronomers happy.
Nope. He used it as an homage, and was sued. The first settlement prevented Apple Computer from entering the music business. There were several subsequent lawsuits, and the final resolution a couple of years ago was Apple Computers buying the Apple brand outright from Apple Corps and renaming itself Apple.
He's right. It doesn't take much longer to turn a page with an eInk device than a real book, but it feels a lot longer. When you turn a page in a book, you're turning a page. When you turn a page with an eInk device, you're waiting for the page to turn. I saw one UI that worked around this by turning the top and bottom halves of the page independently - when you get past the top half, you flip the page turner and it's replaced by the top half of the next page, when you get to the bottom, the next bit is already there and you hit the flip bar to update the bottom. It's a bit clunky, but it works much better than the page-at-a-time model. The problem isn't the speed so much as the interruption. If the speed is fast enough, then you can do it entirely synchronously without there being a problem of interruption.
The sad thing is, none of these old UIs is actually very good. There are numerous ways in which they could be improved, but somehow people always manage to make it worse. Apple has been quite bad at this in recent years, replacing people with a background in psychology with people with a background in graphic design on their UI teams. Microsoft just has such large and disconnected teams that they can't get a cohesive vision together. Google just seems to randomly change things - I can't help wondering if they're using simulated annealing for UI design...
Unfortunately, it's a difficult problem to fix in the current market. Most people evaluate new products based on the 5 minutes they play with the demo, and a flashy UI with serious usability problems often does better than a simple UI where common actions are all trivial in this sort of test. There are several results from the '80s showing exactly this: users being timed over a period of a few weeks performing certain tasks with two interfaces, and very often the one that was faster was not the one that they initially preferred (too lazy to look up the citations, but you can find them around chapter 2 of THE).
He's not entirely wrong. The Hotmail purchase was a bit of an embarrassment at the time for MS. They bought a successful service that was using FreeBSD for everything, while telling all of their customers that UNIX on the server was old and crappy while NT 4 was the new shiny. Then they tried to switch Hotmail to NT4, failed miserably, saw a load of downtime, and reverted to FreeBSD... which would have been fine if they hadn't made such a big deal about the migration. Hotmail now runs Windows Server {some year} - they learned from this experience, improved their server OS offering, and didn't tell anyone about the second migration until after it was done and working.
While I agree with your general point, neither you nor the grandparent has actually given any concrete evidence to support your assertions. For those of us who didn't use the before or after GMail interface, what have they changed and how did it affect usability?
I'd also recommend OpenBSD's spamd. If you're not using OpenBSD, it's also in ports for FreeBSD, and probably available for other platforms. Between it and SpamHaus you catch most spam.
I have a Google Apps account provided by a customer for when they want me to represent them in a semi-official way. I also have email accounts provided by two universities, a university computer club run by volunteers, and one hosted on a VPS that I admin myself. Of these, the one I have been unable to access for the longest in the last year has been the Google-hosted one, followed by mine (server downtime at my old VPS host, I've now moved to another provider), then the computer society.
A $20/month VPS will easily serve a dozen users though. The biggest issue is mail storage space - 1GB/user of space becomes expensive quite quickly. If you and a few friends want email that isn't controlled by a third party, get a VPS together. If there are more than a few, a colocated server can be even cheaper: a machine with a couple of 2TB disks in RAID-1 will happily serve 100 users and give them a lot of space, and if you shop around a bit you can get it for $1-2/month/person. And a server that you control isn't limited to just mail: you can also use it for web hosting and anything else you want. Mine runs a mail server, an XMPP server, a few web sites, and a couple of mailing lists, for example, and the load is low enough that it fits in most VPS providers' cheapest tier. All IM and email goes to domains I own, so I can easily switch.
A lot of VPS providers now provide turn-key VMs with a web control panel, so you don't even need to know very much about system administration to do it, just pick the services you want and tick the relevant checkboxes.
It's easy to abuse undoable moderation. Mod something you disagree with up, wait for it to get 2-3 overrated mods, and then undo it. Rather than making it easy to undo moderation, they should fix the terrible zero-click UI for moderating, so that you need to confirm that you did select the correct post and that you did actually mean that moderation. Or make moderation take a minute to be propagated to the database and allow undo only in this time. A simple finger slip can change the moderation from insightful to troll (or vice versa).
Of course, they still need to find partners willing to use their technology. Pixel Qi, for example, has been pursuing this course, and it's still really hard to find devices that use their screens and often the devices you do find are let down in other areas. If you make a great screen and the first product that a licensee ships has an anaemic CPU and GPU then the poor perception of the device will reflect badly on your screen and may harm future sales ('I got a thing with one of those screens, and it was crap'). That's why it's often a good strategy to put together a reference platform that can show off the functionality for showing to journalists and potential customers, even if you don't sell it as a consumer product.
No, but it's getting close. I have a first generation eInk device, and it takes about 0.9 seconds to do a refresh, so it's managing 1.1fps (and in 16 shades of grey, not colour). The jump from that to 12fps is a lot bigger than the jump from 12fps to 24fps (cinema speed). More importantly, they can have the pixels switch from one colour to another directly, while the earlier ones needed to go via white, which would have made video flickery at any speed.
As they say in the video, it's not 'true video speed', but it does mean that you can have interactive UI widgets on an eInk device. 12fps is enough, for example, to be able to type into a text field without seeing irritating lag. It's enough for buttons to respond as soon as you click on them. It's enough for simple animated effects. I had some pop-up textbooks when I was a child that managed simple animations of things like the inside of a jet engine by having you pull tabs to make parts of a picture move - it's more than enough for that kind of thing, which could be very useful for textbooks.
Yup, it's a shame. I have a WebOS tablet that I was given by HP as an open source developer. The UI is really nice, the hardware is solid (I dropped mine down the stairs and it's still fine, although it chipped the wall on the way down). It wasn't quite in the same league as the iPad, but it was a very solid first entry into the market and with a little bit of tuning could have become a serious contender.
No one confuses an iPad with a MacBook because Mac* and i* are different brands. iOS and Mac OS X are similarly different brands. They both come from Apple, but they're marketed differently. In contrast, Windows 8 and Windows 8 RT are very similar. Microsoft has a difficult balancing act here, because they want to use the recognition of the Windows brand to encourage people to buy based on familiarity, but if they go too far in this direction then they're going to end up with a confusing mess.
Apple had the advantage that the iPod brand was widely recognised by people who had never bought a Mac, and had only vaguely heard of them. The iPhone and iPad built on this brand. Microsoft can't use something like Windows Zune, because the Zune brand isn't exactly respected. They could try to use the XBox brand, which is quite successful, but isn't associated with anything except games.
Slashdot Mirror
The following will have the behaviour that you are claiming:
This will get a compiler error, however consider this version instead:
This will not give a compiler error, but will abort at run time. The type of a string literal is const char * and so it is placed in the constant data section, which may be in ROM on embedded systems and will be mapped read-only (and shared between processes) on other systems. The same problem will happen if you omit the const. The correct way to write this is:
This will give a compiler error on the assignment, because you are attempting to modify constant data. You will also get a compiler warning if you try to implicitly cast to char*, because the code that receives the char* may attempt to modify the data.
Any competent C programmer would use the const only when it's appropriate, to tell the compiler that a symbol isn't a variable
I guess we know exactly where you fit on the C-competence spectrum then...
64 bits. Currently no FPU (but that's being worked on...).
No, permissions are things like execute, read, write. There are also some flags. For example, you can seal a capability and then you can't use it unless it is unsealed by a special form of jump instruction that can be used to implement protection boundaries. The architecture is being developed at Cambridge as part of a DARPA grant to see what you'd do if you were allowed to change anything about computing to improve security: it's a softcore running on an FPGA, running FreeBSD and (almost - I need the latest round of ISA revisions to be finished before I can make everything work) with an LLVM compiler, so we can change any aspect of the stack, from CPU, kernel, compiler and upwards.
If you read The UNIX Haters' Handbook, it proposes exactly this... in the mid '80s. Back then it wasn't even a novel idea, Lisp and Smalltalk environments did it. AppleScript does more or less this, exposing model objects to scripting. With osascript you can run AppleScript scripts from the command line on OS X.
I'm not a huge fan of the PowerShell syntax, but the concept is definitely one of the rare cases of Microsoft copying good ideas, something I wish more tech companies would do more often.
CHERI. It's an experimental MIPS-derived chip that has 32 256-bit capability registers, which are basically fat pointers containing a base, length, and set of permissions.
You mean intptr_t. ptrdiff_t is the largest size of an object. On segmented architectures, it can be the maximum size of a segment. ptrdiff_t is large enough to hold the result of any defined pointer comparison, but pointer comparisons are only defined (in C) on pointers within the same object.
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
On an embedded system, you'll be saving 5-10% memory usage by only supporting X32 and not X64. It may be worth it...
If you are likely to need more than 4GB of RAM, don't compile in X32 mode. Of course, if some of your applications use X32 and some use X64 mode, then you'll need two copies of shared libraries loaded, and one extra copy of glibc is likely to offset all of the benefits of X32 mode unless you are running some very unusually pointer-heavy workloads in the X32 programs.
64 bit architectures give you 64-bit registers and a 64-bit address space (since pointers are, traditionally, integers that fit in registers[1]). On x86, there are a number of other advantages to using the 64-bit long mode: guaranteed SSE so you don't need slow x87 code, more registers, PC-relative addressing (useful for position-independent code) and so on. The cost of using these is that now every pointer is bigger. This has knock-on effects in terms of data cache usage.
The X32 ABI allows you to have all of the benefits of the 64-bit mode except for the larger address space. If you're using under 4GB of memory, then it can, in theory give an improvement in memory and cache usage.
There are two down sides. The first is that, in my testing of C, C++ and Objective-C code, I've found that it's very rare on a 64-bit platform for pointers to account for even 10% of the total memory usage, and usually it's a lot less. This is made worse by the fact that the X64 and X32 ABIs are incompatible, so you may need two copies of the same library in memory if you have code using both.
I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
[1] Not with the architecture I'm currently working with, and I'm spending a lot of time fixing compiler assumptions that this is always the case.
The issue is that a lot of software was written on the assumption that there are 60 seconds in a minute. If something happens at the 61st second of a minute, stuff gets confused. Either it rejects the event, or incorrectly marks the time. Leap seconds are an incredibly expensive idiocy designed to make a few astronomers happy.
Nope. He used it as an homage, and was sued. The first settlement prevented Apple Computer from entering the music business. There were several subsequent lawsuits, and the final resolution a couple of years ago was Apple Computers buying the Apple brand outright from Apple Corps and renaming itself Apple.
I've committed to developing an open source Gmail alternative I can host locally
Why not contribute to improving something like SOGo instead of starting from scratch?
He's right. It doesn't take much longer to turn a page with an eInk device than a real book, but it feels a lot longer. When you turn a page in a book, you're turning a page. When you turn a page with an eInk device, you're waiting for the page to turn. I saw one UI that worked around this by turning the top and bottom halves of the page independently - when you get past the top half, you flip the page turner and it's replaced by the top half of the next page, when you get to the bottom, the next bit is already there and you hit the flip bar to update the bottom. It's a bit clunky, but it works much better than the page-at-a-time model. The problem isn't the speed so much as the interruption. If the speed is fast enough, then you can do it entirely synchronously without there being a problem of interruption.
The sad thing is, none of these old UIs is actually very good. There are numerous ways in which they could be improved, but somehow people always manage to make it worse. Apple has been quite bad at this in recent years, replacing people with a background in psychology with people with a background in graphic design on their UI teams. Microsoft just has such large and disconnected teams that they can't get a cohesive vision together. Google just seems to randomly change things - I can't help wondering if they're using simulated annealing for UI design...
Unfortunately, it's a difficult problem to fix in the current market. Most people evaluate new products based on the 5 minutes they play with the demo, and a flashy UI with serious usability problems often does better than a simple UI where common actions are all trivial in this sort of test. There are several results from the '80s showing exactly this: users being timed over a period of a few weeks performing certain tasks with two interfaces, and very often the one that was faster was not the one that they initially preferred (too lazy to look up the citations, but you can find them around chapter 2 of THE).
He's not entirely wrong. The Hotmail purchase was a bit of an embarrassment at the time for MS. They bought a successful service that was using FreeBSD for everything, while telling all of their customers that UNIX on the server was old and crappy while NT 4 was the new shiny. Then they tried to switch Hotmail to NT4, failed miserably, saw a load of downtime, and reverted to FreeBSD... which would have been fine if they hadn't made such a big deal about the migration. Hotmail now runs Windows Server {some year} - they learned from this experience, improved their server OS offering, and didn't tell anyone about the second migration until after it was done and working.
While I agree with your general point, neither you nor the grandparent has actually given any concrete evidence to support your assertions. For those of us who didn't use the before or after GMail interface, what have they changed and how did it affect usability?
I'd also recommend OpenBSD's spamd. If you're not using OpenBSD, it's also in ports for FreeBSD, and probably available for other platforms. Between it and SpamHaus you catch most spam.
almost never goes down
I have a Google Apps account provided by a customer for when they want me to represent them in a semi-official way. I also have email accounts provided by two universities, a university computer club run by volunteers, and one hosted on a VPS that I admin myself. Of these, the one I have been unable to access for the longest in the last year has been the Google-hosted one, followed by mine (server downtime at my old VPS host, I've now moved to another provider), then the computer society.
A $20/month VPS will easily serve a dozen users though. The biggest issue is mail storage space - 1GB/user of space becomes expensive quite quickly. If you and a few friends want email that isn't controlled by a third party, get a VPS together. If there are more than a few, a colocated server can be even cheaper: a machine with a couple of 2TB disks in RAID-1 will happily serve 100 users and give them a lot of space, and if you shop around a bit you can get it for $1-2/month/person. And a server that you control isn't limited to just mail: you can also use it for web hosting and anything else you want. Mine runs a mail server, an XMPP server, a few web sites, and a couple of mailing lists, for example, and the load is low enough that it fits in most VPS providers' cheapest tier. All IM and email goes to domains I own, so I can easily switch.
A lot of VPS providers now provide turn-key VMs with a web control panel, so you don't even need to know very much about system administration to do it, just pick the services you want and tick the relevant checkboxes.
It's easy to abuse undoable moderation. Mod something you disagree with up, wait for it to get 2-3 overrated mods, and then undo it. Rather than making it easy to undo moderation, they should fix the terrible zero-click UI for moderating, so that you need to confirm that you did select the correct post and that you did actually mean that moderation. Or make moderation take a minute to be propagated to the database and allow undo only in this time. A simple finger slip can change the moderation from insightful to troll (or vice versa).
Of course, they still need to find partners willing to use their technology. Pixel Qi, for example, has been pursuing this course, and it's still really hard to find devices that use their screens and often the devices you do find are let down in other areas. If you make a great screen and the first product that a licensee ships has an anaemic CPU and GPU then the poor perception of the device will reflect badly on your screen and may harm future sales ('I got a thing with one of those screens, and it was crap'). That's why it's often a good strategy to put together a reference platform that can show off the functionality for showing to journalists and potential customers, even if you don't sell it as a consumer product.
No, but it's getting close. I have a first generation eInk device, and it takes about 0.9 seconds to do a refresh, so it's managing 1.1fps (and in 16 shades of grey, not colour). The jump from that to 12fps is a lot bigger than the jump from 12fps to 24fps (cinema speed). More importantly, they can have the pixels switch from one colour to another directly, while the earlier ones needed to go via white, which would have made video flickery at any speed.
As they say in the video, it's not 'true video speed', but it does mean that you can have interactive UI widgets on an eInk device. 12fps is enough, for example, to be able to type into a text field without seeing irritating lag. It's enough for buttons to respond as soon as you click on them. It's enough for simple animated effects. I had some pop-up textbooks when I was a child that managed simple animations of things like the inside of a jet engine by having you pull tabs to make parts of a picture move - it's more than enough for that kind of thing, which could be very useful for textbooks.
Yup, it's a shame. I have a WebOS tablet that I was given by HP as an open source developer. The UI is really nice, the hardware is solid (I dropped mine down the stairs and it's still fine, although it chipped the wall on the way down). It wasn't quite in the same league as the iPad, but it was a very solid first entry into the market and with a little bit of tuning could have become a serious contender.
No one confuses an iPad with a MacBook because Mac* and i* are different brands. iOS and Mac OS X are similarly different brands. They both come from Apple, but they're marketed differently. In contrast, Windows 8 and Windows 8 RT are very similar. Microsoft has a difficult balancing act here, because they want to use the recognition of the Windows brand to encourage people to buy based on familiarity, but if they go too far in this direction then they're going to end up with a confusing mess.
Apple had the advantage that the iPod brand was widely recognised by people who had never bought a Mac, and had only vaguely heard of them. The iPhone and iPad built on this brand. Microsoft can't use something like Windows Zune, because the Zune brand isn't exactly respected. They could try to use the XBox brand, which is quite successful, but isn't associated with anything except games.