I know for a fact that the Sun is the center of our solar system
You are wrong. The barycenter of the solar system is outside the sun.
I think that's rather the point. Science continues to refine knowledge, and past a certain point it gives approximations that are close enough that most people don't have to care that they're wrong. Assuming that the sun and moon go around the Earth is close enough that you can predict seasons, tides, and so on with a reasonable amount of accuracy. Knowing that it is the other way around gives you more accurate understanding of seasons, but is basically only important to meteorologists and people running space ships. Knowing that the complex N-body system of the solar system revolves around a point that is sometimes in the is closer to the truth, but is well past the point of utility for most people.
Similarly, we still teach Newton's laws of motion even though quantum mechanics and relativity mean that we know that they're wrong, it's just that they're wrong by an amount that is far less than the errors from measurement for anything that most people will ever deal with.
Building your own Internet is difficult, but VPNs and onion routers are already pretty well established. The technological solution is to move to protocols where the network has no visibility into the traffic and little visibility regarding the endpoints.
And this is why I don't really see the point of Swift. If you want to avoid run-time overhead from Objective-C but want to maintain compatibility with Objective-C libraries, there's already a language that lets you do this: Objective-C++. You can use C++ templates for compile-time specialisation and Objective-C for late binding. Objective-C ARC now makes this combination cleaner, because Objective-C object pointers are non-POD types in C++ and all of the memory management interoperates cleanly. It's also easy to use some simple wrappers to use C++ range-based for loops to iterate over characters in an Objective-C string or index set. Clang also handles transparently interoperating between C++ lambdas and Objective-C blocks.
Swift feels like a vanity project. The difficult problems in language design are concurrency, error handling, and compartmentalisation. Swift didn't even try to address any of these until later revisions.
And for the guy who asked about Smalltalk - the Xerox machine which first used mouse and Icons was a hardware Smalltalk machine.
No it wasn't. It was a Xerox Alto. The Alto was a microcoded 16-bit system, and each language that was developed for it wrote its own microcode. The Alto processor was designed to execute bytecode, with each one being implemented by running the microcode provided for that index. Smalltalk bytecode was just one of the microcode implementations, the Algol virtual machine (for example) provided a different bytecode. This mechanism went out of fashion when people became interested in running programs written in more than one language without rebooting in between.
Your argument would make sense, if not for the fact that Apple has been moving in the other direction recently. For example, you can now install any app on iOS devices that you compile for yourself. A useful feature for geeks, not so much for average consumers.
As to sandboxing, the principle of least privilege is good engineering. As long as the user can define the restrictions and can run things with full privileges when required.
That said, DOSBox on non-x86 hardware does emulate 16-bit and works very well. It was fast enough to run Worms (which I originally played on a Pentium) on my 1GHz PowerPC Mac and has emulated CPU speed control so I could use it to run a bunch of things that hadn't worked correctly since the original PC because they assumed that they could use delay loops for timing.
Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.
I'd be very surprised if they weren't entirely microcode today. Who cares if every real mode instruction takes 10 cycles to complete - no customers large enough to care about have performance critical real-mode code, and the few that do are probably happy if it's a few thousand times faster than their 80286. If it's in microcode, it's taking a trivial amount of die space and none in performance-critical parts.
If you want to use SecureBoot and the TPM to provide a chain of trust then you don't want an attacker to be able to flip a DIP switch and disable it. The kind of customers that really want this sort of thing are people who want to stick a load of machines in a data centre that's managed by someone else and be sure that no one on site can tamper with them without being detected.
Following the links a bit, it looks as if El Capitan is still getting security updates and supports Mid-2007 15" and 17" MacBook Pros (MacBooks Pro?), and all 13" ones. It's not the latest OS, but High Sierra is such a QA clusterfuck that there's little incentive to upgrade (scaled resolution on an external display pegs CPU at 100%, so good luck having a battery last for an entire presentation, and it's crashing on a lot of hardware that was stable with Sierra) and Sierra didn't include much by way of useful additional features.
The problem with rotting is that the goal isn't to reduce carbon dioxide, it's to reduce the greenhouse effect. The processes involved in rotting release a lot of methane, which is a much worse greenhouse gas and then breaks down to carbon dioxide.
I work at Amazon at AWS. One of our main principles is customer obsession - we try REALLY hard not to break any customers' workflows. Sometimes it means supporting awkward API features misconceived more than 10 years ago.
So, exactly like Microsoft in the mid '90s then? Remember Windows 95, which would detect SimCity binaries and defer returning memory to the OS when running them so that a use-after-free bug that worked fine in DOS didn't crash in Windows 95? Or any of the other few hundred hacks that they had? Or the security nightmare of Windows XP that came from relaxing the Windows NT security policies to avoid breaking code written for Windows 95? I'd be hard pressed to think of a company that's invested more than Microsoft in avoiding breaking third-party code. None of this was for altruistic reasons - legacy Win16 and then Win32 applications were what kept people buying Windows. Break them, and porting them or rewriting them to work on new Windows suddenly becomes a thing that businesses evaluate alongside porting them to another OS (or turning them into web apps).
The key difference is that this terminal is now not a source of lock in. If you have a web app, the odds are that the client side of it will run on a Windows PC, a Surface tablet, an iPad, Android tablet, or Chromebook without any issues. Porting the server side to a different cloud provider is harder, which is why this is the thing that matters for business now.
Americans with Disabilities Act. I wouldn't be surprised if he had a strong case. He wrote a memo and circulated it internally for feedback. In a sane world, people in the company would have said that his logic is okay, but his axioms are backed up by some quite non-representative and cherry-picked studies. He would then have been pointed at some other sources and modified the document before circulating it more widely. Instead, the memo was sent to the press and Google fired him for embarrassing the company, which amounts to firing him for being autistic (and is illegal under the ADA).
My mother worked at a library for a few years after retiring as a teacher. She didn't have a library services degree, though she would have needed to do a one-year masters for promotion to some of the more senior positions (given that she was retiring completely after a few years, she didn't bother, but if she'd wanted to they'd have paid for the tuition and let her do it part time). She was responsible for organising a couple of volunteers for most of that time.
You can male things cost $1 and people will still bitch about it and rationalize their theft.
You can make things $1, and some people will still bitch about it. We've recently been buying a lot of TV shows on DVD, because the prices are crazily low now so many people are moving to streaming services. Second-hand boxed sets are about £2-3 and even new they're about £5, so about 25p/episode, in a format that I can rip if I want to take some of it on a laptop or tablet on a train or plane. I recently bought a complete boxed set of The Sopranos for about £5. At that sort of price, for a lot of people, it's cheaper to just pay than to even bother trying to pirate.
My first trip to Japan involved having to get back to Tokyo by taking a regional train and then switching to the Shinkansen. I had about 5 minutes to make the connection and I was worried that I'd be late if the train was delayed. My host drew me a map of the station and the symbols I needed to look for to find the right platform. The little rural train arrived exactly on time. It took me 4 minutes to walk to the departure platform, at which point I saw a large digital clock counting down from one minute. The Shinkansen stopped as it reached 0, at which point it started counting down to the departure time.
I actually forgot to allow enough time for check in at the airport and arrived 30 minutes before departure as the people at the check-in desk were packing up to go home. They managed to rush my suitcase to the plane and took me through the pilots' entrance to the secured area so I bypassed most of the security and showed me to the departure gate so I didn't lose any time getting lost - I ended up having to wait around for 10 minutes for boarding to start. Slightly traumatic, but the fastest airport experience I've ever had. If flying were always like that, I wouldn't find it nearly as annoying!
It's worse than that. A modern digital thermostat is programmable and the entire system is not much more expensive than an old-style analogue one. Throw in an Internet connection, and you get to pay double the price to be dependent on some cloud provider (and your ISP) for working heating. Hmm, which one should I buy...?
I suspect it's a mixture of several reasons. In no particular order:
Complexity implies unreliability. Something with a simple mechanical switch is likely to be (or, at least, perceived to be likely to be) more durable than something with a microprocessor, a smartphone app, and some cloudy things.
Most 'home automation things are not actually useful.
They're all big on vendor lock-in. This means that you're screwed if the vendor goes out of business, but it also means that devices from different vendors don't play nice together. People don't actually want to have 20 apps installed on their phones to control different aspects of their homes.
They're getting a reputation for poor security - who wants their home to advertise to potential burglars that they're going to be out for the next few hours?
Even when they have decent security, that just means that unauthorised people won't get the data, it doesn't mean that the vendor won't be spying on you and selling info about the inside of your house.
Even the useful things are very expensive both in relation to build costs and to utility.
They're so very hipster that if you don't live in the Bay Area you'd be deeply embarrassed if any of your friends saw that you owned one.
So, what you're saying, is that you have a different definition of open source to the rest of the world (if you don't agree with the definition from the OSI, which is the consensus agreed on by a large number of open source contributors and distributors, look at the FSF's Four Freedoms or the Debian Open Source Guidelines, which are all roughly equivalent). That's fine, and you're free to make up your own definitions of words, but you don't then get to call out other people for using the consensus definitions: Open source means what the people who coined the term use it to mean, and that usage is embodied in the OSI definition.
Is there any winning when it comes to memory-management? As in, an IR that works nicely for both GC'ed an non-GC'ed memory-management?
The requirements for GC are pretty simple: you must be able to identify pointers, updates to pointers must be atomic, and pointers must not be materialised from integers. For efficiency, you might want read or write barriers, but if you have this data in your IR then you can insert these depending on what your GC requires. If you keep those in your IR, so that things like intptr_t are implemented as tagged unions of a pointer and an integer and carry their pointerness around with them, then you can implement it. It's also possible for an IR to support safe and unsafe pointers (I think the CLR can do this, but I've not looked in detail), so the non-GC'd pointers are just offsets into a large heap and the GC'd pointers require some special handling. That's basically the model that WebAssembly has anyway: pointers are actually relative to a region, so different libraries can have private heaps and pointers into them, which isn't really different from having a bunch of TypedArray JavaScript objects and using offsets in them as non-GC'd pointers.
As you say, it's awkward to shoehorn manual memory-management onto the JVM, and it's also awkward going the other way - LLVM is known for being an amazing platform but hard to use with GC.
There are two conflated issues here. LLVM is bad for GC both because it didn't have any real notion of GC and because most of the optimisers didn't think about GC. The new safepoint stuff lets Azul have a high-performance accurate GC. It basically looks like a function call that identifies all of the variables that are meant to be live, and allows them to be relocated. LLVM IR is now pretty GC-friendly, it's just that some of the optimisation passes are not (in particular, we and Azul both had to do some things to ensure that it didn't try to insert integer-to-pointer casts in unexpected places).
You're wrong. Go check the license. Go look up what "open source" means.
Okay, here's the definition. Please point to anything in that definition that contradicts what I've said.
Receiving rights from your contractors is something that everybody always gets.
If only that were true. A huge amount of code is written on contract but then received with a proprietary license that locks the customer into the vendor for any support.
All closed source software written by contractors comes with an implicit license
It comes with a license to use (typically within an organisation), it usually doesn't permit modification or redistribution.
Compared to the entire standard Red Hat installation, the number of CVEs times their CVSS severity is roughly ten times higher for Windows 8.
You'll forgive me if I don't trust your number when you seem to be unaware of recent kernel vulnerabilities and haven't published your methodology.
Oh, and it's worth noting that a number of the CVEs related to the USB stack are impossible for any certified drivers on Windows because they're required to pass a static analysis check that would catch them (Microsoft had a few hundred CVEs for similar bugs some years back when they introduced this policy).
Slashdot Mirror
I know for a fact that the Sun is the center of our solar system
You are wrong. The barycenter of the solar system is outside the sun.
I think that's rather the point. Science continues to refine knowledge, and past a certain point it gives approximations that are close enough that most people don't have to care that they're wrong. Assuming that the sun and moon go around the Earth is close enough that you can predict seasons, tides, and so on with a reasonable amount of accuracy. Knowing that it is the other way around gives you more accurate understanding of seasons, but is basically only important to meteorologists and people running space ships. Knowing that the complex N-body system of the solar system revolves around a point that is sometimes in the is closer to the truth, but is well past the point of utility for most people.
Similarly, we still teach Newton's laws of motion even though quantum mechanics and relativity mean that we know that they're wrong, it's just that they're wrong by an amount that is far less than the errors from measurement for anything that most people will ever deal with.
Building your own Internet is difficult, but VPNs and onion routers are already pretty well established. The technological solution is to move to protocols where the network has no visibility into the traffic and little visibility regarding the endpoints.
And this is why I don't really see the point of Swift. If you want to avoid run-time overhead from Objective-C but want to maintain compatibility with Objective-C libraries, there's already a language that lets you do this: Objective-C++. You can use C++ templates for compile-time specialisation and Objective-C for late binding. Objective-C ARC now makes this combination cleaner, because Objective-C object pointers are non-POD types in C++ and all of the memory management interoperates cleanly. It's also easy to use some simple wrappers to use C++ range-based for loops to iterate over characters in an Objective-C string or index set. Clang also handles transparently interoperating between C++ lambdas and Objective-C blocks.
Swift feels like a vanity project. The difficult problems in language design are concurrency, error handling, and compartmentalisation. Swift didn't even try to address any of these until later revisions.
And for the guy who asked about Smalltalk - the Xerox machine which first used mouse and Icons was a hardware Smalltalk machine.
No it wasn't. It was a Xerox Alto. The Alto was a microcoded 16-bit system, and each language that was developed for it wrote its own microcode. The Alto processor was designed to execute bytecode, with each one being implemented by running the microcode provided for that index. Smalltalk bytecode was just one of the microcode implementations, the Algol virtual machine (for example) provided a different bytecode. This mechanism went out of fashion when people became interested in running programs written in more than one language without rebooting in between.
Your argument would make sense, if not for the fact that Apple has been moving in the other direction recently. For example, you can now install any app on iOS devices that you compile for yourself. A useful feature for geeks, not so much for average consumers.
As to sandboxing, the principle of least privilege is good engineering. As long as the user can define the restrictions and can run things with full privileges when required.
They don't, but for a long time most of iCloud was hosted on Azure. I think it's mostly moved to Apple's own datacentres now though.
That said, DOSBox on non-x86 hardware does emulate 16-bit and works very well. It was fast enough to run Worms (which I originally played on a Pentium) on my 1GHz PowerPC Mac and has emulated CPU speed control so I could use it to run a bunch of things that hadn't worked correctly since the original PC because they assumed that they could use delay loops for timing.
Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.
I'd be very surprised if they weren't entirely microcode today. Who cares if every real mode instruction takes 10 cycles to complete - no customers large enough to care about have performance critical real-mode code, and the few that do are probably happy if it's a few thousand times faster than their 80286. If it's in microcode, it's taking a trivial amount of die space and none in performance-critical parts.
If you want to use SecureBoot and the TPM to provide a chain of trust then you don't want an attacker to be able to flip a DIP switch and disable it. The kind of customers that really want this sort of thing are people who want to stick a load of machines in a data centre that's managed by someone else and be sure that no one on site can tamper with them without being detected.
Following the links a bit, it looks as if El Capitan is still getting security updates and supports Mid-2007 15" and 17" MacBook Pros (MacBooks Pro?), and all 13" ones. It's not the latest OS, but High Sierra is such a QA clusterfuck that there's little incentive to upgrade (scaled resolution on an external display pegs CPU at 100%, so good luck having a battery last for an entire presentation, and it's crashing on a lot of hardware that was stable with Sierra) and Sierra didn't include much by way of useful additional features.
Internet without Google and Facebook? Yes please!
The problem with rotting is that the goal isn't to reduce carbon dioxide, it's to reduce the greenhouse effect. The processes involved in rotting release a lot of methane, which is a much worse greenhouse gas and then breaks down to carbon dioxide.
I work at Amazon at AWS. One of our main principles is customer obsession - we try REALLY hard not to break any customers' workflows. Sometimes it means supporting awkward API features misconceived more than 10 years ago.
So, exactly like Microsoft in the mid '90s then? Remember Windows 95, which would detect SimCity binaries and defer returning memory to the OS when running them so that a use-after-free bug that worked fine in DOS didn't crash in Windows 95? Or any of the other few hundred hacks that they had? Or the security nightmare of Windows XP that came from relaxing the Windows NT security policies to avoid breaking code written for Windows 95? I'd be hard pressed to think of a company that's invested more than Microsoft in avoiding breaking third-party code. None of this was for altruistic reasons - legacy Win16 and then Win32 applications were what kept people buying Windows. Break them, and porting them or rewriting them to work on new Windows suddenly becomes a thing that businesses evaluate alongside porting them to another OS (or turning them into web apps).
The key difference is that this terminal is now not a source of lock in. If you have a web app, the odds are that the client side of it will run on a Windows PC, a Surface tablet, an iPad, Android tablet, or Chromebook without any issues. Porting the server side to a different cloud provider is harder, which is why this is the thing that matters for business now.
Americans with Disabilities Act. I wouldn't be surprised if he had a strong case. He wrote a memo and circulated it internally for feedback. In a sane world, people in the company would have said that his logic is okay, but his axioms are backed up by some quite non-representative and cherry-picked studies. He would then have been pointed at some other sources and modified the document before circulating it more widely. Instead, the memo was sent to the press and Google fired him for embarrassing the company, which amounts to firing him for being autistic (and is illegal under the ADA).
My mother worked at a library for a few years after retiring as a teacher. She didn't have a library services degree, though she would have needed to do a one-year masters for promotion to some of the more senior positions (given that she was retiring completely after a few years, she didn't bother, but if she'd wanted to they'd have paid for the tuition and let her do it part time). She was responsible for organising a couple of volunteers for most of that time.
You can male things cost $1 and people will still bitch about it and rationalize their theft.
You can make things $1, and some people will still bitch about it. We've recently been buying a lot of TV shows on DVD, because the prices are crazily low now so many people are moving to streaming services. Second-hand boxed sets are about £2-3 and even new they're about £5, so about 25p/episode, in a format that I can rip if I want to take some of it on a laptop or tablet on a train or plane. I recently bought a complete boxed set of The Sopranos for about £5. At that sort of price, for a lot of people, it's cheaper to just pay than to even bother trying to pirate.
My first trip to Japan involved having to get back to Tokyo by taking a regional train and then switching to the Shinkansen. I had about 5 minutes to make the connection and I was worried that I'd be late if the train was delayed. My host drew me a map of the station and the symbols I needed to look for to find the right platform. The little rural train arrived exactly on time. It took me 4 minutes to walk to the departure platform, at which point I saw a large digital clock counting down from one minute. The Shinkansen stopped as it reached 0, at which point it started counting down to the departure time.
I actually forgot to allow enough time for check in at the airport and arrived 30 minutes before departure as the people at the check-in desk were packing up to go home. They managed to rush my suitcase to the plane and took me through the pilots' entrance to the secured area so I bypassed most of the security and showed me to the departure gate so I didn't lose any time getting lost - I ended up having to wait around for 10 minutes for boarding to start. Slightly traumatic, but the fastest airport experience I've ever had. If flying were always like that, I wouldn't find it nearly as annoying!
That's an exaggeration. It's only a problem if they're the wrong kind of leaves.
It's worse than that. A modern digital thermostat is programmable and the entire system is not much more expensive than an old-style analogue one. Throw in an Internet connection, and you get to pay double the price to be dependent on some cloud provider (and your ISP) for working heating. Hmm, which one should I buy...?
So, what you're saying, is that you have a different definition of open source to the rest of the world (if you don't agree with the definition from the OSI, which is the consensus agreed on by a large number of open source contributors and distributors, look at the FSF's Four Freedoms or the Debian Open Source Guidelines, which are all roughly equivalent). That's fine, and you're free to make up your own definitions of words, but you don't then get to call out other people for using the consensus definitions: Open source means what the people who coined the term use it to mean, and that usage is embodied in the OSI definition.
Is there any winning when it comes to memory-management? As in, an IR that works nicely for both GC'ed an non-GC'ed memory-management?
The requirements for GC are pretty simple: you must be able to identify pointers, updates to pointers must be atomic, and pointers must not be materialised from integers. For efficiency, you might want read or write barriers, but if you have this data in your IR then you can insert these depending on what your GC requires. If you keep those in your IR, so that things like intptr_t are implemented as tagged unions of a pointer and an integer and carry their pointerness around with them, then you can implement it. It's also possible for an IR to support safe and unsafe pointers (I think the CLR can do this, but I've not looked in detail), so the non-GC'd pointers are just offsets into a large heap and the GC'd pointers require some special handling. That's basically the model that WebAssembly has anyway: pointers are actually relative to a region, so different libraries can have private heaps and pointers into them, which isn't really different from having a bunch of TypedArray JavaScript objects and using offsets in them as non-GC'd pointers.
As you say, it's awkward to shoehorn manual memory-management onto the JVM, and it's also awkward going the other way - LLVM is known for being an amazing platform but hard to use with GC.
There are two conflated issues here. LLVM is bad for GC both because it didn't have any real notion of GC and because most of the optimisers didn't think about GC. The new safepoint stuff lets Azul have a high-performance accurate GC. It basically looks like a function call that identifies all of the variables that are meant to be live, and allows them to be relocated. LLVM IR is now pretty GC-friendly, it's just that some of the optimisation passes are not (in particular, we and Azul both had to do some things to ensure that it didn't try to insert integer-to-pointer casts in unexpected places).
You're wrong. Go check the license. Go look up what "open source" means.
Okay, here's the definition. Please point to anything in that definition that contradicts what I've said.
Receiving rights from your contractors is something that everybody always gets.
If only that were true. A huge amount of code is written on contract but then received with a proprietary license that locks the customer into the vendor for any support.
All closed source software written by contractors comes with an implicit license
It comes with a license to use (typically within an organisation), it usually doesn't permit modification or redistribution.
And I can point to 40 in the Linux kernel's USB stack alone from this month
Okay, go!
Okay, here you go.
No? How about 4? Still no? Maybe 3? How about ANY at all?
Did I not mention I curate a database of every CVE ever issued? My team looks at each and every one.
Doing a great job, if you miss ones that even The Registers notices
Compared to the entire standard Red Hat installation, the number of CVEs times their CVSS severity is roughly ten times higher for Windows 8.
You'll forgive me if I don't trust your number when you seem to be unaware of recent kernel vulnerabilities and haven't published your methodology.
Oh, and it's worth noting that a number of the CVEs related to the USB stack are impossible for any certified drivers on Windows because they're required to pass a static analysis check that would catch them (Microsoft had a few hundred CVEs for similar bugs some years back when they introduced this policy).