If you think professors (the ones he said were making 'low six figures') are 'admin folks' (the ones he said were making 'jack', then I suspect you were ripped off for your degree.
That doesn't prevent the normal way of recruiting via internships. The internship is a fixed-duration placement over a summer break and you're offered a job at the completion of your degree. The offer won't come for a few months after the end of the internship and will be contingent on the degree result.
Why didn't Apple give Mac OS X (AKA NeXTSTEP, AKA macOS) a different name that wouldn't be confused with Mac OS (AKA System, AKA System Softwware), given that they're completely different and basically incompatible operating systems?
I don't know about you, but I was able to run all of the MacOS 9 applications that I tried on Mac OS X. I started playing Diablo II again recently: Blizzard only released a native OS X installer a few years ago, prior to that the installer on the disk was a classic binary and needed to run in the emulator (which only worked on PowerPC, making it impossible to install on modern Macs).
There's a growing movement towards preventing implicit casts in programming languages, because they're a common source of bug. The sane fix for this issue in Python would be to require that the / operand has the same types on both sides.
C++'s std::auto_ptr was deprecated in C++11 because it's almost impossible to use correctly and code using it is trivial to migrate to using unique_ptr - if it isn't, then that's usually an indication that there were subtle bugs in the original that now become compile failures. In spite of that, it's still there in C++11 and C++14 and wasn't removed until C++17. You can still compile code as C++14 and use it, it's just a terrible idea.
Or places like the USA, where Facebook builds profiles about the issues of importance and opinions of the electorate, identifies the marginal voters in swing constituencies and the issues that will persuade them to change their vote, and sells this to the party that bids the highest. And, for an extra fee, will even put adds saying 'Candidate X supports {Issue that you think is the most important}' in their feeds.
Exactly. In a high-demand field, a paid internship is a cheap way of hiring: you get to spend three months finding out if your prospective employee is competent and they get to spend three months deciding if they want to work for you (and, if they are competent, you get to spend three months persuading them that they do). In comparison with pretty much any other hiring mechanism, a paid internship is very cheap, in a field where there's a skills shortage. If companies in a field can easily hire competent people without this, then that's a good indication that there's a glut of talent.
The goal is to protect the motorist. Even if the pedestrian completely deserved to be removed from the gene pool, accidentally killing someone who walks into the street is quite traumatic and the idiots looking at their phones shouldn't have the right to inflict that on a random stranger.
which is incidentally the first YouTube ad I've seen whose makers had picked up on the simple and obvious fact any content beyond 5 seconds in a YouTube ad is wasted
This is the one that really amazes me. You can skip the ad after 5 seconds, so you have 5 seconds to convince me not to (or, at least, to try to make me aware of your brand). So many YouTube ads spend the first 5 seconds on some build effect so that by the time I hit 'skip ad' I have no idea what company or product is being advertised.
Most fuel stations provide at least one grade of diesel and at least one kind of petrol. Mandating a small number of connectors for different vehicle capabilities isn't a problem, especially if they're designed so that the high-current ones support a lower-current supply and gracefully fall back to the slower mode.
Remember ActiveX? There were a lot of things wrong with the design, but one of the worst things that it did, from a security perspective, was condition users to hit 'okay' to dialog boxes saying 'this bit of untrusted code needs complete access to your computer, allow?' Android has done the same thing: encouraged users to accept that every app needs complete access to your call log, browsing history, text message history, and so on.
iOS is somewhat better in this regard, because apps are expected to start with no permissions and prompt for permissions that they need as they need them. Most non-malicious apps need few permissions and users get into the habit of tapping 'deny' when the permission doesn't seem like one that the app should need.
Note that this has nothing to do with Linux vs XNU (both models could easily be implemented on either kernel), it is a UI design issue and Apple is generally a lot better than Google at HCI.
It's still XNU and it still contains some Mach things, though system calls are just system calls and talk directly to the BSD server without going via Mach ports (which was what really hurt performance on early Mach implementations). They also completely rewrote the VM subsystem around 10.4/5, which improved performance dramatically. FreeBSD's VM is based on the old Mach VM, but has had a lot of refactorings, cleanups, and rewrites of important parts since then, OS X 10.0 was still pretty close to the CMU version (right down to support for external pagers). There's a lot of FreeBSD code in the XNU kernel, including things like kqueue (though extended to support Mach ports) and even more in libc, which is why it's usually a lot easier to port OS X code to FreeBSD than Linux.
Installing LineageOS requires a certain level of technical competence, but that's true for pretty much any OS. That's a one-off thing though, and once it's installed the updates come over the air and just require you to tap on the notification and agree to install them. I wouldn't recommend a nontechnical user installs it, but I've had no problem installing it for nontechnical users and then letting them use the device without any additional support.
If they offered zero security, then that would be one thing. In fact, they often offer negative security. Last year, there was a vulnerability in Norton Antivirus that allowed arbitrary kernel-mode code execution. It would detect new files in the filesystem and scan them in the kernel (stupid design decision number one: the code scanning untrusted and expected-to-be-malicious data should be an unprivileged userspace process with read-only access to precisely one file). Unfortunately, their image decoder contained a vulnerability, so if your web browser or mail client dropped a png file on the filesystem, even if the user didn't ever open it, the system was compromised. Other AVs have had similar vulnerabilities. You're running some code that hooks into the OS, written by people that don't have access to the OS source code and don't know how many of the internals work, with maximum possible privilege. Does that sound like a good plan to you?
I don't really have a problem with Apple dropping support for old versions of the OS - you can't expect a device to come with unlimited support for the lifetime of the hardware without paying for a support contract. I do have a problem with the fact that the bootloader remains locked and much of the SoC remains undocumented at the end of that. I also have a problem with the fact that they never tell you when they're going to drop support in advance.
If I buy a PC, it typically comes with an OS that has a fixed support window, know ahead of time. Sometimes (as with Windows XP), that's extended for a bit, but you know that it will end and you know roughly when it will end. The next version of the OS from the same vendor might not work with your hardware, but you can always get a third-party OS to run on it. Many of us first ran Linux or *BSD on computers that were given to us or bought cheaply because Windows no longer ran well on them. The hardware may not serve its original purpose, but it's still useable.
The same is true with most Android devices. When an Android phone or tablet no longer gets first-party security updates, you can unlock the bootloader and install a third-party OS that is able to use all of the functionality.
I would love to see right to repair laws require that companies unlock bootloaders and provide all documentation required to support the hardware as soon as they stop shipping security updates.
Huh? I had a WebOS tablet a couple of years after iOS and Android were released (I already owned an Android phone at the time). WebOS had a clean and well-designed UI and I'd have done more work on it if HP hadn't decided to kill the line completely shortly after I got mine.
Don't be silly. They'll pay this out of money sitting in the US, so that they can report a $2bn loss, which should nicely offset a big chunk of tax. It's only money coming in that you don't want to put on your books in the US, money going out always comes from the jurisdictions with the highest tax rates.
Apple supports its devices far longer than anyone else does. It seems silly to complain about Appleâ(TM)s upgrade cycle when many Android devices donâ(TM)t get more than 1-2 major OS releases.
Apple has better first-party support, but once they stop shipping security updates then the device is a brick. Actually, it's worse: it's a network-enabled device with known remotely exploitable vulnerabilities that can be used as an entry point for attacking the rest of your network.
My mobile phone is a Moto G. It's a cheap piece of crap that I bought 3 years ago when Motorola was owned by Google and was expecting to get long-term support. Google sold Motorola shortly after. It got major updates for about a year and then security patches (often months after the vulnerability was publicly disclosed) for about another year. That sounds a lot worse than the Apple option, but there's a big difference: I can go over to LineageOS and get a version of Android that's based on the latest version.
The same is true with an old Mac: once it stops getting macOS updates, I can always install FreeBSD or something else on it. With an iOS device, the bootloader is locked and remains locked even when all it's doing is locking you to a known-insecure OS.
And, with iOS 4.3, you only have about 50 known remotely exploitable vulnerabilities, so it's probably completely safe to use, as long as the WiFi is disabled.
You too disliked that name? I found it to be a tad hubris - much preferred PC-BSD.
TrueOS sounds too much like Tru64 to me, and that's not a particularly positive association. The Oppose Sun Foundation had some good ideas, but a lot of bad ones and Tru64 managed to combine the worst parts of a monolithic kernel and a microkernel (as did NeXTSTEP and early versions of OS X) without getting most of the benefits.
You seem to be implying that FreeBSD is going to immediately port all their 3rd party software to any new GCC that gets released in the future during the support period, but that is not actually how FreeBSD versions work
I didn't mention GCC. The default compiler for anything that hasn't actively been marked as requiring GCC is clang. The ports framework has flags to indicate required features of a compiler. If a port is marked as needing C++14, then it will be compiled with either the system compiler (if it supports one), or one from ports if required. The infrastructure for doing this is used automatically by the package-building infrastructure, so a port that needs a newer compiler than the one shipped in the base system will automatically get the one from ports.
The actual reality is that FreeBSD will get most new versions later than even Centos!
An assertion without evidence. We run a few CentOS machines at work and getting anything that needs a newer C++ version than was available when the base OS shipped is a huge amount of pain. Let's look at available packages for CentOS 7 and FreeBSD 10 (both released 2014 and still supported). What's the latest clang version available for them? Actually, that doesn't seem to be a fair comparison, because CentOS doesn't seem to include clang packages (and LLVM is only packaged for MESA) but, for reference, FreeBSD 10 has packages for clang 3.8 to to the 5.0 release branch (5.0 isn't yet out, but there are packages for the latest snapshot from the release branch). Okay, let's make a more fair comparison: how about gcc, since that's the system compiler for CentOS? Well, the CentOS package list has a compat package for GCC 4.4 for compiling older stuff, and an up-to-date package for GCC 4.8.5 (released June 2015), which predates most C++14 features. So, as I said, compiling C++14 code on CentOS is a pain. Okay, let's look at FreeBSD. GCC isn't the system compiler and you've said it lags updates and is behind CentOS, so I guess it will be older? I see packages for GCC 4.6, 4.7, 4.8, 4.9, 5.4 (after 5.0, GCC changed its release numbering, so 5.x is a release series, previously 4.9.x was a release series), 6.4, 7.11, and the (unreleased) 8 release branch.
And no, they don't just slavishly follow the upstream release schedule, they actually couldn't do what you imply if they wanted to because so much of their 3rd party software gets local changes to make it more secure, which then isolates them from upstream and means new versions have to be basically back-ported. So you don't even get all the released versions.
Again, look in the ports collection (follow the svnweb link next to any port to see the history of files that have changed). Most ports have no patches, or trivial ones to change a couple of paths in the build system, and these typically don't change much between upstream versions other than being removed if they're upstreamed.
Stable is only useful if it's both stable and usable. The system ABIs across a stable FreeBSD release series are guaranteed to be compatible, but that doesn't mean that you can't run newer software and there's little use in a system with long-term support if support just means 'we won't change anything' - that's not support, that's atrophy.
Both Capsicum and the Apple Sandbox framework are designed support dynamically granting running applications access to specific files from outside. In Capsicum, you simply pass a file descriptor to the file over a UNIX domain socket. In the Apple Sandbox framework, you have APIs to dynamically add the path to that file to the process's ACL (these are integrated into things like the open file dialog and are easy to add to a command-line tool).
Safari does exactly what I want from a browser: Gives me a web view with a minimal UI and gets out of the way, while integrating with the rest of the system cleanly (e.g. using the keychain for storing credentials) and using OS sandboxing to isolate renderers. Well, actually, unlike Chrome, the Apple devs did the split in WebKit so Safari doesn't actually do this, any consumer of the WebKit framework gets sandboxing for free, whereas Blink requires everyone to implement their own sandboxing.
Increasingly, programmers rely on an ever expanding set of tools to do all of the hard work, don't know or care about performance or efficiency, and write bloated messes.
There's nothing wrong with using tools. If there's a well-written library that does something, then you can focus on the things that you're an expert in and allow people who are experts in something else to optimise their library. The problem is that programmers are increasingly bad at judging the quality of the libraries that they use.
You're probably better off trying TruOS (once you get past the stupid name). It's a FreeBSD friendly fork, which includes some improvements to the UI for initial setup and also merges a load of stuff that isn't yet in mainline FreeBSD (newer versions of GPU drivers, for example).
Slashdot Mirror
If you think professors (the ones he said were making 'low six figures') are 'admin folks' (the ones he said were making 'jack', then I suspect you were ripped off for your degree.
That doesn't prevent the normal way of recruiting via internships. The internship is a fixed-duration placement over a summer break and you're offered a job at the completion of your degree. The offer won't come for a few months after the end of the internship and will be contingent on the degree result.
Why didn't Apple give Mac OS X (AKA NeXTSTEP, AKA macOS) a different name that wouldn't be confused with Mac OS (AKA System, AKA System Softwware), given that they're completely different and basically incompatible operating systems?
I don't know about you, but I was able to run all of the MacOS 9 applications that I tried on Mac OS X. I started playing Diablo II again recently: Blizzard only released a native OS X installer a few years ago, prior to that the installer on the disk was a classic binary and needed to run in the emulator (which only worked on PowerPC, making it impossible to install on modern Macs).
dafueq who thought of this is a good idea?
There's a growing movement towards preventing implicit casts in programming languages, because they're a common source of bug. The sane fix for this issue in Python would be to require that the / operand has the same types on both sides.
C++'s std::auto_ptr was deprecated in C++11 because it's almost impossible to use correctly and code using it is trivial to migrate to using unique_ptr - if it isn't, then that's usually an indication that there were subtle bugs in the original that now become compile failures. In spite of that, it's still there in C++11 and C++14 and wasn't removed until C++17. You can still compile code as C++14 and use it, it's just a terrible idea.
Or places like the USA, where Facebook builds profiles about the issues of importance and opinions of the electorate, identifies the marginal voters in swing constituencies and the issues that will persuade them to change their vote, and sells this to the party that bids the highest. And, for an extra fee, will even put adds saying 'Candidate X supports {Issue that you think is the most important}' in their feeds.
Exactly. In a high-demand field, a paid internship is a cheap way of hiring: you get to spend three months finding out if your prospective employee is competent and they get to spend three months deciding if they want to work for you (and, if they are competent, you get to spend three months persuading them that they do). In comparison with pretty much any other hiring mechanism, a paid internship is very cheap, in a field where there's a skills shortage. If companies in a field can easily hire competent people without this, then that's a good indication that there's a glut of talent.
The goal is to protect the motorist. Even if the pedestrian completely deserved to be removed from the gene pool, accidentally killing someone who walks into the street is quite traumatic and the idiots looking at their phones shouldn't have the right to inflict that on a random stranger.
which is incidentally the first YouTube ad I've seen whose makers had picked up on the simple and obvious fact any content beyond 5 seconds in a YouTube ad is wasted
This is the one that really amazes me. You can skip the ad after 5 seconds, so you have 5 seconds to convince me not to (or, at least, to try to make me aware of your brand). So many YouTube ads spend the first 5 seconds on some build effect so that by the time I hit 'skip ad' I have no idea what company or product is being advertised.
Most fuel stations provide at least one grade of diesel and at least one kind of petrol. Mandating a small number of connectors for different vehicle capabilities isn't a problem, especially if they're designed so that the high-current ones support a lower-current supply and gracefully fall back to the slower mode.
Remember ActiveX? There were a lot of things wrong with the design, but one of the worst things that it did, from a security perspective, was condition users to hit 'okay' to dialog boxes saying 'this bit of untrusted code needs complete access to your computer, allow?' Android has done the same thing: encouraged users to accept that every app needs complete access to your call log, browsing history, text message history, and so on.
iOS is somewhat better in this regard, because apps are expected to start with no permissions and prompt for permissions that they need as they need them. Most non-malicious apps need few permissions and users get into the habit of tapping 'deny' when the permission doesn't seem like one that the app should need.
Note that this has nothing to do with Linux vs XNU (both models could easily be implemented on either kernel), it is a UI design issue and Apple is generally a lot better than Google at HCI.
It's still XNU and it still contains some Mach things, though system calls are just system calls and talk directly to the BSD server without going via Mach ports (which was what really hurt performance on early Mach implementations). They also completely rewrote the VM subsystem around 10.4/5, which improved performance dramatically. FreeBSD's VM is based on the old Mach VM, but has had a lot of refactorings, cleanups, and rewrites of important parts since then, OS X 10.0 was still pretty close to the CMU version (right down to support for external pagers). There's a lot of FreeBSD code in the XNU kernel, including things like kqueue (though extended to support Mach ports) and even more in libc, which is why it's usually a lot easier to port OS X code to FreeBSD than Linux.
Installing LineageOS requires a certain level of technical competence, but that's true for pretty much any OS. That's a one-off thing though, and once it's installed the updates come over the air and just require you to tap on the notification and agree to install them. I wouldn't recommend a nontechnical user installs it, but I've had no problem installing it for nontechnical users and then letting them use the device without any additional support.
If they offered zero security, then that would be one thing. In fact, they often offer negative security. Last year, there was a vulnerability in Norton Antivirus that allowed arbitrary kernel-mode code execution. It would detect new files in the filesystem and scan them in the kernel (stupid design decision number one: the code scanning untrusted and expected-to-be-malicious data should be an unprivileged userspace process with read-only access to precisely one file). Unfortunately, their image decoder contained a vulnerability, so if your web browser or mail client dropped a png file on the filesystem, even if the user didn't ever open it, the system was compromised. Other AVs have had similar vulnerabilities. You're running some code that hooks into the OS, written by people that don't have access to the OS source code and don't know how many of the internals work, with maximum possible privilege. Does that sound like a good plan to you?
If I buy a PC, it typically comes with an OS that has a fixed support window, know ahead of time. Sometimes (as with Windows XP), that's extended for a bit, but you know that it will end and you know roughly when it will end. The next version of the OS from the same vendor might not work with your hardware, but you can always get a third-party OS to run on it. Many of us first ran Linux or *BSD on computers that were given to us or bought cheaply because Windows no longer ran well on them. The hardware may not serve its original purpose, but it's still useable.
The same is true with most Android devices. When an Android phone or tablet no longer gets first-party security updates, you can unlock the bootloader and install a third-party OS that is able to use all of the functionality.
I would love to see right to repair laws require that companies unlock bootloaders and provide all documentation required to support the hardware as soon as they stop shipping security updates.
Huh? I had a WebOS tablet a couple of years after iOS and Android were released (I already owned an Android phone at the time). WebOS had a clean and well-designed UI and I'd have done more work on it if HP hadn't decided to kill the line completely shortly after I got mine.
Don't be silly. They'll pay this out of money sitting in the US, so that they can report a $2bn loss, which should nicely offset a big chunk of tax. It's only money coming in that you don't want to put on your books in the US, money going out always comes from the jurisdictions with the highest tax rates.
Apple supports its devices far longer than anyone else does. It seems silly to complain about Appleâ(TM)s upgrade cycle when many Android devices donâ(TM)t get more than 1-2 major OS releases.
Apple has better first-party support, but once they stop shipping security updates then the device is a brick. Actually, it's worse: it's a network-enabled device with known remotely exploitable vulnerabilities that can be used as an entry point for attacking the rest of your network.
My mobile phone is a Moto G. It's a cheap piece of crap that I bought 3 years ago when Motorola was owned by Google and was expecting to get long-term support. Google sold Motorola shortly after. It got major updates for about a year and then security patches (often months after the vulnerability was publicly disclosed) for about another year. That sounds a lot worse than the Apple option, but there's a big difference: I can go over to LineageOS and get a version of Android that's based on the latest version.
The same is true with an old Mac: once it stops getting macOS updates, I can always install FreeBSD or something else on it. With an iOS device, the bootloader is locked and remains locked even when all it's doing is locking you to a known-insecure OS.
And, with iOS 4.3, you only have about 50 known remotely exploitable vulnerabilities, so it's probably completely safe to use, as long as the WiFi is disabled.
You too disliked that name? I found it to be a tad hubris - much preferred PC-BSD.
TrueOS sounds too much like Tru64 to me, and that's not a particularly positive association. The Oppose Sun Foundation had some good ideas, but a lot of bad ones and Tru64 managed to combine the worst parts of a monolithic kernel and a microkernel (as did NeXTSTEP and early versions of OS X) without getting most of the benefits.
You seem to be implying that FreeBSD is going to immediately port all their 3rd party software to any new GCC that gets released in the future during the support period, but that is not actually how FreeBSD versions work
I didn't mention GCC. The default compiler for anything that hasn't actively been marked as requiring GCC is clang. The ports framework has flags to indicate required features of a compiler. If a port is marked as needing C++14, then it will be compiled with either the system compiler (if it supports one), or one from ports if required. The infrastructure for doing this is used automatically by the package-building infrastructure, so a port that needs a newer compiler than the one shipped in the base system will automatically get the one from ports.
The actual reality is that FreeBSD will get most new versions later than even Centos!
An assertion without evidence. We run a few CentOS machines at work and getting anything that needs a newer C++ version than was available when the base OS shipped is a huge amount of pain. Let's look at available packages for CentOS 7 and FreeBSD 10 (both released 2014 and still supported). What's the latest clang version available for them? Actually, that doesn't seem to be a fair comparison, because CentOS doesn't seem to include clang packages (and LLVM is only packaged for MESA) but, for reference, FreeBSD 10 has packages for clang 3.8 to to the 5.0 release branch (5.0 isn't yet out, but there are packages for the latest snapshot from the release branch). Okay, let's make a more fair comparison: how about gcc, since that's the system compiler for CentOS? Well, the CentOS package list has a compat package for GCC 4.4 for compiling older stuff, and an up-to-date package for GCC 4.8.5 (released June 2015), which predates most C++14 features. So, as I said, compiling C++14 code on CentOS is a pain. Okay, let's look at FreeBSD. GCC isn't the system compiler and you've said it lags updates and is behind CentOS, so I guess it will be older? I see packages for GCC 4.6, 4.7, 4.8, 4.9, 5.4 (after 5.0, GCC changed its release numbering, so 5.x is a release series, previously 4.9.x was a release series), 6.4, 7.11, and the (unreleased) 8 release branch.
And no, they don't just slavishly follow the upstream release schedule, they actually couldn't do what you imply if they wanted to because so much of their 3rd party software gets local changes to make it more secure, which then isolates them from upstream and means new versions have to be basically back-ported. So you don't even get all the released versions.
Again, look in the ports collection (follow the svnweb link next to any port to see the history of files that have changed). Most ports have no patches, or trivial ones to change a couple of paths in the build system, and these typically don't change much between upstream versions other than being removed if they're upstreamed.
Stable is only useful if it's both stable and usable. The system ABIs across a stable FreeBSD release series are guaranteed to be compatible, but that doesn't mean that you can't run newer software and there's little use in a system with long-term support if support just means 'we won't change anything' - that's not support, that's atrophy.
Both Capsicum and the Apple Sandbox framework are designed support dynamically granting running applications access to specific files from outside. In Capsicum, you simply pass a file descriptor to the file over a UNIX domain socket. In the Apple Sandbox framework, you have APIs to dynamically add the path to that file to the process's ACL (these are integrated into things like the open file dialog and are easy to add to a command-line tool).
Safari does exactly what I want from a browser: Gives me a web view with a minimal UI and gets out of the way, while integrating with the rest of the system cleanly (e.g. using the keychain for storing credentials) and using OS sandboxing to isolate renderers. Well, actually, unlike Chrome, the Apple devs did the split in WebKit so Safari doesn't actually do this, any consumer of the WebKit framework gets sandboxing for free, whereas Blink requires everyone to implement their own sandboxing.
Increasingly, programmers rely on an ever expanding set of tools to do all of the hard work, don't know or care about performance or efficiency, and write bloated messes.
There's nothing wrong with using tools. If there's a well-written library that does something, then you can focus on the things that you're an expert in and allow people who are experts in something else to optimise their library. The problem is that programmers are increasingly bad at judging the quality of the libraries that they use.
You're probably better off trying TruOS (once you get past the stupid name). It's a FreeBSD friendly fork, which includes some improvements to the UI for initial setup and also merges a load of stuff that isn't yet in mainline FreeBSD (newer versions of GPU drivers, for example).