Except that Apple Mail.app, while not flawless by any stretch, is a really great mail client. Android has some good ones too: K9 is only missing cross-account message store/move and it'd be as good as mail.app. I've tried Microsoft Mail a few times and decided that it just doesn't work (for me.) Outlook works, for small values of work, but is the sort of obliquely painful experience that you'd expect of an unloved "legacy" technology.
Microsoft wants you to transition to MS Teams. It also doesn't work, but it's much shinier than their mail offerings and has the advantage of locking you and your content into their infrastructure.
This isn't even remotely true. Sure, housing is vastly more expensive everywhere in the world at the moment (not just the US), but that is mostly the effect of extremely low interest rates and the common case of two adults in employment to pay the mortgages. All else follows according to supply and demand. Look at the fraction of household income paid on mortgages, and that will be nearly the same as it was fifty years ago. It's what people will stand.
The issue isn't that web sites are doing real-time analytics. It's that they've all out-sourced the process to a handful of third party companies. No one cares that the information they've provided to the company they are interacting with over SSL gets seen by that company: of course it does. What they care about is that this stream of data is parceled up and sent (not necessarily securely, according to the article) to some company you've never heard of, and have no business relationship with.
ACK Basic on a TRS-80. Wasn't very long before that was swept away by Z80 assembly language though. I remember magazines of the day containing articles that included listings (can't remember if it was asm or hex) that I would diligently enter. And then debug. I don't think that reading hex opcodes is something that the youft still get to experience, more's the pity.
Javascript is OK. It's a bit like lisp in sheep's clothing, and that goes all the way back to the beginning.
Highschool was only more Basic I think. University started with a local dialect of Object-Pascal and a little Fortran. C came later.
I don't think that there is enough emphasis on assembly language these days. By by the time I had graduated I had used assembly for Z-80 and 8085, 68000, NS16032, VAX, PDP-11. Maybe early SPARC. Perhaps TI DSP32010. One machine that I built myself for a project. Probably 8086 and 80286. ARMv2.
Lisp and its decendents (everything that uses garbage collection) are OK for theory and explorartory programming. Practice is important though. You have to understand what things cost, and why.
a) 64 bit processors can do 64-bit arithmetic in a single cycle. b) The 64-bit processors in question have more named registers (fewer stack spills), and a significantly more efficient function calling convention (ABI) c) 64-bit ABI doesn't touch the old x87 register set, which is another net performance win. (Not that VS2015 will use this much.) Ergo: most of the time they are faster. The only way to make a 64-bit program slower than a 32-bit one is to have enough pointer-chasing and associated irregular dynamic data that the change in pointer size materially affects the data cache miss rate. Certainly there is some code like that: VS2015 might even be an example.
How fast do you need your IDE to be though, and how much is performance really the instruction set's fault? Versions of Visual Studio have been produced that run in everything from.NET to JavaScript, and that's fair because most of the cycles are going to be consumed in GUI and file stacks anyway. Native code performance is hardly going to be the issue.
The issue is almost certainly that LLP64 is a dumb idea, and the code base will have lots and lots of pieces of historical code that assume that you can manipulate pointers with long arithmetic, and all of those are going to have to be found and fixed by hand, often involving real understanding and design decisions.
Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.
Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.
With a slight caveat that in that last one percent is probably the use case of DOM inside a browser page looks sufficiently like an irreducible thicket of tiny objects, and still wants all the speed that it can get, which is why Google is pushing x32 for Chrome plugins. Maybe it helps a bit for Javascript compilation too.
At least if your x32 is (a) sandboxed in a browser process and (b) generated by a JIT then the library duplication badness should be negligible and the result mostly invisible to the user.
For my own code, I wouldn't touch it with a bargepole. Storing pointers in memory? Madness...
HTML5/WebGL/etc not doing it for you? They say it's all the rage.
Personally, I prefer X11R5 or DisplayPostscript, but these wheels have to be re-invented every so often, in case "round" stops being the right answer...
You've seen a lot of applications that work like that?
Sure it might be feasible. Might even happen, one day. Isn't the case now though, and I think that you're radically under-estimating the amount of re-work (basically re-design) that would be required to have fully-useful two-mode applications.
There are some, I suppose. Apple's got versions of Pages and their other iWork applications that run in desktop and tablet mode. So they're probably ahead of the game as far as useful convergence is concerned.
Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.
It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.
How can a task manager be "mind blowingly awesome"? Having to use a task manager at all is a fairly sure sign that things are not going well. That they've made that some sort of central feature is, IMO, a bit worrying.
Similarly: I've never used a platform other than windows where the act of copying or moving files around in the filesystem was so painful, or where there could be a reasonable cause to pretty up the dialog enough that you'd notice it. Everywhere else moves are normally instantaneous (unless to other filesystems) and copies are just copies. Yes, I am not a fan of MacOS asking whether you want to overwrite target files either: Unix had this right in the first place: unless it's locked down, in which case the action is failed, if I say I want to copy that over there, then that's what I want to happen. If I make a mistake I can jolly well recover from backup, or run around screaming.
I switched to MacOS from FreeBSD a few years ago because using appropriate proprietary graphics drivers weren't an issue (and always will be an issue on FreeBSD, as far as I can see), and because I wanted to use Lightroom for my photography hobby. That's all, but they're two things that I can't see changing any time soon. Switching to windows wouldn't have worked, because although I want those two specific features, I don't want to lose my comfy BSD/Posix command line environment. The windows command line experience has been astonishingly awful for its entire existence, so it is not something I can expect to change any time soon. I don't think that Ubuntu is in a measurably different position to FreeBSD in this.
Most of the whinging seems to centre around the existence of an app-store (which, as someone who uses FreeBSD ports and apt-get on a regular basis is simply a good idea, not something to be afraid of) and the (optional) removal of permanently-visible scroll-bars in favour of multi-touch swiping on the track-pad (or mouse-wheel, I suppose.) I count both of them improvements, but clearly tastes differ.
Real iOS-ification would be sandboxing applications so that they can't operate on arbitrary files in the file system, and removal of access to said file-system. I can't really see either of those happening.
Personally, I can see where the tea-leaves are pointing, and am in the progress of moving all of my daily activity into a personal "cloud" hosted on my own FreeBSD box. Then I can use osx or android or whatever has the good proprietary graphics stack at the time and just get on with it.
I think that you'll find that a fair chunk of the top-end of the top500 (and the graph500) are IBM Blue-something systems that run variants of Power. These are essentially descendants of the PowerPC440 series of embedded processors: not terribly fierce on their own, but have a significant advantage for this sort of work: they don't consume much power. So you can run a *lot* of them with a limited power budget. Much like ARM, which is why several folk, including AMD, are lining up to do server versions of AArch64.
Which is why Facebook and others have created the Open Server Aliance, and why Intel, AMD and ARM are all members, and are all producing CPU+memory modules to suit that space.
Low power devices are the present and the future, even if you need the power supply of a medium-sized town to run the data-centre.
The patents and the compatibility in question relate specifically to the way Microsoft encoded the long-file-name compatibility, and the short-form-contraction extensions into the FAT directory structure. It's an ugly hack that no-one with skill in the art would think of doing, so it's a legitimate patent. I don't know why camera makers don't just limit themselves to the 8.3 filename space and avoid even dealing with long file names: every camera I know of seems to work like that anyway.
The primary work-around du-jour (and it's a good one) is USB-PTP protocol (and variants) that avoid the question by not exposing the block device structure at all: operate more like a network file system. Makes perfect sense. This is why lots of mobile devices don't have SD card slots. Add an SD card slot and you have to support FAT or exFAT. Leave the slot out and you can run ext2 or whatever on your internal flash drive, and expose files to the external world over wifi or USB-PTP.
Since the controllers in SD cards are computers too, it would probably be feasible to build some sort of SD card variant that spoke PTP directly, but how likely is that?
I read a little of the on-line doco, and noticed that the "native development" system supports C++ but not exceptions. So two-phase object initialisation is a requirement and try/except is out, and a bunch of standard APIs can't be used. There was also something about restrictions on C use, should you prefer that, but also missing some standard library functions. That's not too surprising, but I suspect that the C++ restriction is going to make porting code from existing sources painful. I dimly remember C++ under Symbian being odd, for similar reasons. Maybe for exactly the same reasons and with the same heritage?
NeXT wasn't the only, or even the first OS that had vector graphics baked in at a low level. Acorn's RiscOS was all vector graphics and scalable, anti-aliased fonts from the late '80s on, on a 4MHz processor that had no cache and a dumb frame buffer in bandwidth-sucking "shared DRAM". True, it didn't have much in the way of actual resolution either, but it did work very well. Performance of the vector drawing primitives was never a big issue. That was a machine that was in the same ballpark as the IBM PC-XT (which was a contemporary), price-wise.
That's not it at all: tablets are now (or will be soon) just "screens": no different from the one in your lounge room or on front of the fridge. The circuits are just moving around a bit. If you want to *do* something with it, you'll be able to use that box with the hard drives and the peripherals sitting in the corner of your office just as easily as you can now, or you can rent space on someone's cloud server, if you prefer.
Don't think of it as losing your PC. It's more the case that your laptop/desktop monitor can still do a range of useful things after the "PC" has been powered down. There are already plenty of manufacturers who have the clue, and are selling WiFi enabled network hard drives: "personal cloud" systems.
No, Outlook with Exchange is terrible on many levels. Probably Exchange's fault, and the fact that it doesn't use IMAP. Every time I have to fire the beast up for some reason, it takes more than half an hour to "synch" to my mailbox. How is that even possible over gigabit ethernet? Why, every time? Does it forget everything it ever synched the last time? Rubbish.
Non-braindamaged message composition, sane integration with the rest of the native applications that I use, off-line access, seamless integration of multiple accounts and, oh, speed. Built-in searching, and integration with the platform's native searching are bonuses. Oh, and not being in a web browser.
BTW: Mail.app has some faults, but as an IMAP client (with dovecot back-end) I've met nothing that comes close. (OK, claws-mail is fairly close, but lack of html/rich-text composition is limiting in some contexts.) I would *love* to have something as good as Mail.app on Linux/FreeBSD.
Limiting factor these days is how much power you can get in and out of the box. They will have optimized for that. And these processors probably do have GPUs on them.
"Films" (at least the big-budget, blockbuster ones) haven't been recorded on "film" for years. Everything is video. Not VHS video, but electronic. That's one of the reasons why Kodak is out of business. Certainly some smaller film companies are probably still using actual film, but it's not mainstream. I haven't checked but I would be *very* surprised if any film stock was harmed in the making of the Hobbit.
"That quantization can be heard." Only if you go and turn the volume up at that point, so that those quiet pieces are loud. (And that's why you want a larger bit-depth while recording and mixing, because mixing some parts up is something that you're doing.) If you don't go and fiddle with the volume knob, then you're competing against the noise floor of the listening environment. Even the quietest suburban listening rooms+hi-fi kit only have 85-or so dB peak-to-noise range, so the 16-bit CD's 120-ish floor is plenty.
There is essentially no virtue in a compressed filesystem because there is essentially no compressible data on a modern file system. The bulk of user data these days (by volume) is already compressed, as JPEG images or MPEG sound files, or similar. A very few people or situations will have a fair chunk of information in the form of documents and guess what: the modern forms of those are already compressed too (zipped XML is the new doc.)
The pieces of data that people will complain about, executables and libraries, aren't particularly compressible either, and are not useful in compressed form because the modern operating systems that execute them operate by demand paging. Everything else (directory structure, control files) is in the noise, and arguably much better off uncompressed for efficiency of access.
Slashdot Mirror
99% of my passwords are ssh passwords. How does this help me?
If you're using passwords with ssh, then you're doing it wrong.
Also, not every new thing has to benefit everyone. Companies introduce new things that are no help to me all the time...
Except that Apple Mail.app, while not flawless by any stretch, is a really great mail client.
Android has some good ones too: K9 is only missing cross-account message store/move and it'd be as good as mail.app.
I've tried Microsoft Mail a few times and decided that it just doesn't work (for me.) Outlook works, for small values of work, but is the sort of obliquely painful experience that you'd expect of an unloved "legacy" technology.
Microsoft wants you to transition to MS Teams. It also doesn't work, but it's much shinier than their mail offerings and has the advantage of locking you and your content into their infrastructure.
This isn't even remotely true. Sure, housing is vastly more expensive everywhere in the world at the moment (not just the US), but that is mostly the effect of extremely low interest rates and the common case of two adults in employment to pay the mortgages. All else follows according to supply and demand. Look at the fraction of household income paid on mortgages, and that will be nearly the same as it was fifty years ago. It's what people will stand.
The issue isn't that web sites are doing real-time analytics. It's that they've all out-sourced the process to a handful of third party companies. No one cares that the information they've provided to the company they are interacting with over SSL gets seen by that company: of course it does. What they care about is that this stream of data is parceled up and sent (not necessarily securely, according to the article) to some company you've never heard of, and have no business relationship with.
ACK Basic on a TRS-80. Wasn't very long before that was swept away by Z80 assembly language though. I remember magazines of the day containing articles that included listings (can't remember if it was asm or hex) that I would diligently enter. And then debug. I don't think that reading hex opcodes is something that the youft still get to experience, more's the pity.
Javascript is OK. It's a bit like lisp in sheep's clothing, and that goes all the way back to the beginning.
Highschool was only more Basic I think. University started with a local dialect of Object-Pascal and a little Fortran. C came later.
I don't think that there is enough emphasis on assembly language these days. By by the time I had graduated I had used assembly for Z-80 and 8085, 68000, NS16032, VAX, PDP-11. Maybe early SPARC. Perhaps TI DSP32010. One machine that I built myself for a project. Probably 8086 and 80286. ARMv2.
Lisp and its decendents (everything that uses garbage collection) are OK for theory and explorartory programming. Practice is important though. You have to understand what things cost, and why.
a) 64 bit processors can do 64-bit arithmetic in a single cycle.
b) The 64-bit processors in question have more named registers (fewer stack spills), and a significantly more efficient function calling convention (ABI)
c) 64-bit ABI doesn't touch the old x87 register set, which is another net performance win. (Not that VS2015 will use this much.)
Ergo: most of the time they are faster.
The only way to make a 64-bit program slower than a 32-bit one is to have enough pointer-chasing and associated irregular dynamic data that the change in pointer size materially affects the data cache miss rate. Certainly there is some code like that: VS2015 might even be an example.
How fast do you need your IDE to be though, and how much is performance really the instruction set's fault? Versions of Visual Studio have been produced that run in everything from .NET to JavaScript, and that's fair because most of the cycles are going to be consumed in GUI and file stacks anyway. Native code performance is hardly going to be the issue.
The issue is almost certainly that LLP64 is a dumb idea, and the code base will have lots and lots of pieces of historical code that assume that you can manipulate pointers with long arithmetic, and all of those are going to have to be found and fixed by hand, often involving real understanding and design decisions.
Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.
Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.
This.
With a slight caveat that in that last one percent is probably the use case of DOM inside a browser page looks sufficiently like an irreducible thicket of tiny objects, and still wants all the speed that it can get, which is why Google is pushing x32 for Chrome plugins. Maybe it helps a bit for Javascript compilation too.
At least if your x32 is (a) sandboxed in a browser process and (b) generated by a JIT then the library duplication badness should be negligible and the result mostly invisible to the user.
For my own code, I wouldn't touch it with a bargepole. Storing pointers in memory? Madness...
HTML5/WebGL/etc not doing it for you? They say it's all the rage.
Personally, I prefer X11R5 or DisplayPostscript, but these wheels have to be re-invented every so often, in case "round" stops being the right answer...
You've seen a lot of applications that work like that?
Sure it might be feasible. Might even happen, one day. Isn't the case now though, and I think that you're radically under-estimating the amount of re-work (basically re-design) that would be required to have fully-useful two-mode applications.
There are some, I suppose. Apple's got versions of Pages and their other iWork applications that run in desktop and tablet mode. So they're probably ahead of the game as far as useful convergence is concerned.
Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.
It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.
How can a task manager be "mind blowingly awesome"? Having to use a task manager at all is a fairly sure sign that things are not going well. That they've made that some sort of central feature is, IMO, a bit worrying.
Similarly: I've never used a platform other than windows where the act of copying or moving files around in the filesystem was so painful, or where there could be a reasonable cause to pretty up the dialog enough that you'd notice it. Everywhere else moves are normally instantaneous (unless to other filesystems) and copies are just copies. Yes, I am not a fan of MacOS asking whether you want to overwrite target files either: Unix had this right in the first place: unless it's locked down, in which case the action is failed, if I say I want to copy that over there, then that's what I want to happen. If I make a mistake I can jolly well recover from backup, or run around screaming.
I switched to MacOS from FreeBSD a few years ago because using appropriate proprietary graphics drivers weren't an issue (and always will be an issue on FreeBSD, as far as I can see), and because I wanted to use Lightroom for my photography hobby. That's all, but they're two things that I can't see changing any time soon. Switching to windows wouldn't have worked, because although I want those two specific features, I don't want to lose my comfy BSD/Posix command line environment. The windows command line experience has been astonishingly awful for its entire existence, so it is not something I can expect to change any time soon. I don't think that Ubuntu is in a measurably different position to FreeBSD in this.
Most of the whinging seems to centre around the existence of an app-store (which, as someone who uses FreeBSD ports and apt-get on a regular basis is simply a good idea, not something to be afraid of) and the (optional) removal of permanently-visible scroll-bars in favour of multi-touch swiping on the track-pad (or mouse-wheel, I suppose.) I count both of them improvements, but clearly tastes differ.
Real iOS-ification would be sandboxing applications so that they can't operate on arbitrary files in the file system, and removal of access to said file-system. I can't really see either of those happening.
Personally, I can see where the tea-leaves are pointing, and am in the progress of moving all of my daily activity into a personal "cloud" hosted on my own FreeBSD box. Then I can use osx or android or whatever has the good proprietary graphics stack at the time and just get on with it.
I think that you'll find that a fair chunk of the top-end of the top500 (and the graph500) are IBM Blue-something systems that run variants of Power. These are essentially descendants of the PowerPC440 series of embedded processors: not terribly fierce on their own, but have a significant advantage for this sort of work: they don't consume much power. So you can run a *lot* of them with a limited power budget. Much like ARM, which is why several folk, including AMD, are lining up to do server versions of AArch64.
Which is why Facebook and others have created the Open Server Aliance, and why Intel, AMD and ARM are all members, and are all producing CPU+memory modules to suit that space.
Low power devices are the present and the future, even if you need the power supply of a medium-sized town to run the data-centre.
The patents and the compatibility in question relate specifically to the way Microsoft encoded the long-file-name compatibility, and the short-form-contraction extensions into the FAT directory structure. It's an ugly hack that no-one with skill in the art would think of doing, so it's a legitimate patent. I don't know why camera makers don't just limit themselves to the 8.3 filename space and avoid even dealing with long file names: every camera I know of seems to work like that anyway.
The primary work-around du-jour (and it's a good one) is USB-PTP protocol (and variants) that avoid the question by not exposing the block device structure at all: operate more like a network file system. Makes perfect sense. This is why lots of mobile devices don't have SD card slots. Add an SD card slot and you have to support FAT or exFAT. Leave the slot out and you can run ext2 or whatever on your internal flash drive, and expose files to the external world over wifi or USB-PTP.
Since the controllers in SD cards are computers too, it would probably be feasible to build some sort of SD card variant that spoke PTP directly, but how likely is that?
I read a little of the on-line doco, and noticed that the "native development" system supports C++ but not exceptions. So two-phase object initialisation is a requirement and try/except is out, and a bunch of standard APIs can't be used. There was also something about restrictions on C use, should you prefer that, but also missing some standard library functions. That's not too surprising, but I suspect that the C++ restriction is going to make porting code from existing sources painful. I dimly remember C++ under Symbian being odd, for similar reasons. Maybe for exactly the same reasons and with the same heritage?
NeXT wasn't the only, or even the first OS that had vector graphics baked in at a low level. Acorn's RiscOS was all vector graphics and scalable, anti-aliased fonts from the late '80s on, on a 4MHz processor that had no cache and a dumb frame buffer in bandwidth-sucking "shared DRAM". True, it didn't have much in the way of actual resolution either, but it did work very well. Performance of the vector drawing primitives was never a big issue. That was a machine that was in the same ballpark as the IBM PC-XT (which was a contemporary), price-wise.
That's not it at all: tablets are now (or will be soon) just "screens": no different from the one in your lounge room or on front of the fridge. The circuits are just moving around a bit. If you want to *do* something with it, you'll be able to use that box with the hard drives and the peripherals sitting in the corner of your office just as easily as you can now, or you can rent space on someone's cloud server, if you prefer.
Don't think of it as losing your PC. It's more the case that your laptop/desktop monitor can still do a range of useful things after the "PC" has been powered down. There are already plenty of manufacturers who have the clue, and are selling WiFi enabled network hard drives: "personal cloud" systems.
No, Outlook with Exchange is terrible on many levels. Probably Exchange's fault, and the fact that it doesn't use IMAP. Every time I have to fire the beast up for some reason, it takes more than half an hour to "synch" to my mailbox. How is that even possible over gigabit ethernet? Why, every time? Does it forget everything it ever synched the last time? Rubbish.
Non-braindamaged message composition, sane integration with the rest of the native applications that I use, off-line access, seamless integration of multiple accounts and, oh, speed. Built-in searching, and integration with the platform's native searching are bonuses. Oh, and not being in a web browser.
BTW: Mail.app has some faults, but as an IMAP client (with dovecot back-end) I've met nothing that comes close. (OK, claws-mail is fairly close, but lack of html/rich-text composition is limiting in some contexts.) I would *love* to have something as good as Mail.app on Linux/FreeBSD.
Limiting factor these days is how much power you can get in and out of the box. They will have optimized for that. And these processors probably do have GPUs on them.
"Films" (at least the big-budget, blockbuster ones) haven't been recorded on "film" for years. Everything is video. Not VHS video, but electronic. That's one of the reasons why Kodak is out of business. Certainly some smaller film companies are probably still using actual film, but it's not mainstream. I haven't checked but I would be *very* surprised if any film stock was harmed in the making of the Hobbit.
This 48 Hz issue is a different problem.
"That quantization can be heard."
Only if you go and turn the volume up at that point, so that those quiet pieces are loud. (And that's why you want a larger bit-depth while recording and mixing, because mixing some parts up is something that you're doing.) If you don't go and fiddle with the volume knob, then you're competing against the noise floor of the listening environment. Even the quietest suburban listening rooms+hi-fi kit only have 85-or so dB peak-to-noise range, so the 16-bit CD's 120-ish floor is plenty.
There is essentially no virtue in a compressed filesystem because there is essentially no compressible data on a modern file system. The bulk of user data these days (by volume) is already compressed, as JPEG images or MPEG sound files, or similar. A very few people or situations will have a fair chunk of information in the form of documents and guess what: the modern forms of those are already compressed too (zipped XML is the new doc.)
The pieces of data that people will complain about, executables and libraries, aren't particularly compressible either, and are not useful in compressed form because the modern operating systems that execute them operate by demand paging. Everything else (directory structure, control files) is in the noise, and arguably much better off uncompressed for efficiency of access.