FWIW, the situation is a bit more nuanced than that.

If the GPL licensed code is entirely your own work, you can relicense it any way you want, including to Apple for distribution on the App Store.

Where you can get into trouble with the App Store is if you take someone else GPL'd code and release it on the App Store. This could be by including third-party GPL routines, or by publishing code that was developed by multiple parties, without their permission, where copyright has not been reassigned. This was the case for the VLC player: as the article you linked alludes, Apple took that old VLC player app out of their app store due to a copyright complaint from one of the VLC developers. That was back in 2011 -- the VideoLAN Oragniaztaion has since released their own VLC for iOS, while still retaining the GPL license (albeit in part by dual-licensing it as MPL/GPL).

Yaz (IANAL)

Sony pretty actively advertises that the PS4 HDD is completely user-upgradable. IIRC the PS4 manual contains instructions, and they also have them online here.

I've read articles that have tested magnetic, SSD, and Hybrid(SSHD) drives, and they all work just fine. The main limitations appear to be in terms of physical size (2.5" drive, 9.5mm or less in height). Word has it you can use up to a 6TB drive, although the people doing so are using 3.5" drives in external enclosures (and I've read some reports of some weird issues with powering such systems up).

Yaz

Which is all well and good if you're doing greenfield development. It's not so good when you're inherited a codebase where none of this was done in the first place, and you're tasked to keep it going. As I said, the real world can be a messy place. In my case, the previous lead architect just threw immature libraries at every problem willy-nilly, at a time before I worked for the company. I get to inherit the problems this lack of foresight caused, and don't have the benefit of going backwards to fix it.

I don't disagree -- I'm hardly anti-library (you won't get too far in development without them, unless you're doing low-level embedded work). I like a good, stable, well-designed library that has been around for a long time, and where breaking changes are rare. Unfortunately, when the previous architect would throw a library at every problem that may have required eight lines of code, without care for anything other than ensuring the library license permits us to ship it.

And FWIW, I have brought these issues up with management. Their stance is they don't want to see any backend changes of any sort (where the bulk of our library woes lie) -- their focus is on the front end only. They're more than happy to defer the risks to some unspecified future.

As I said, the real world of development can be messy. I'm stuck with a codebase that is full of immature libraries, libraries that are no longer maintained, and libraries with bugs where getting new libraries introduces major changes requiring major refactors. If I were permitted to start fresh, I'd be doing things the way you described, and we wouldn't rely so much on "randomLibrary.jar" that was someones pet project seven years ago with 'LGPL' attached to it, but which has since been rewritten or abandoned. It's a willy-nilly application of such libraries to every problem that crops up without any analysis that I'm against, and not the use of libraries in any and all situations.

Yaz

Part of the problem I run into with this is that sometimes projects stick with old dependencies because at some point, some major version came along that significantly changed the organization of the API in such a way that the latest component version an't just be dropped in, but requires significant resources refactoring your code to use it. Getting management buy-in for that when there aren't any big customers breathing down their neck to get a flaw fixed can be neigh on impossible.

I ran into this recently myself. During internal testing, I discovered a flaw in our product when accessing any of our web resources using an IPv6 destination IP in the URL (i.e.: http://18080./ A quick bit of debugging showed that an external library we had been using for several years was doing some brain-dead parsing of the URL to pull out the port number; it was just doing a string split after the first colon it found, and presumed the rest was the port number.

Modifying the Maven POM to use a newer version of the API in question was initially difficult because the project had since reorganized their own library structure, breaking things into multiple smaller JARs. Except that some of the functionality was actually _removed_, and isn't available at the latest API revision (functionality we had been using, naturally). Classes had moved around to different packages than where they were previously, and various interfaces appear to have been completely rewritten.

Upgrading to a version of the library that actually fixed the flaw was going to be akin to opening Pandora's Box. Unfortunately, our former architect (from whom I inherited this code) was the type of guy who just liked to throw external libraries at every problem. In the end we had to document the fault for all current versions of the product, and now I'm trying to get management buy-in to do the work necessary to upgrade the library in question for the next version of our product. And this is for just one library out of over 100 that need similar attention.

Suffice to say, I'm not happy about this state of affairs. Unlike the previous architect, I push against using third-party libraries as our solution to everything. If I were allowed to rewrite everything from scratch, we could avoid these problems. Things are unfortunately messy out here in the real world, and when libraries decide to significantly change their interfaces your program uses to access their functionality, no amount of unit tests is going to make upgrading those libraries any easier.

Yaz

If you haven't spent an afternoon saying "Ni!" to your colleagues, you may turn in your geek/nerd card on your way out.

By way of penance, you must return here with a shrubbery, or else you will never pass through this wood alive. One that looks nice. And not too expensive.

Now go!

I'm sometimes surprised that more people don't know this, but you don't have to turn off the "scary security dialogs" to run unsigned apps on OS X.

While the standard double-click on such an application will bring up a security dialog, if you use right click -> Open instead you'll get a different security dialog with an option not present not he default dialog that permits you to whitelist the application in question. Once whitelisted, you won't be bothered about code signing for that application ever again.

Yaz

What, do you mean like with WebKit or CUPS?

Sorry, but past performance shows you are wrong. FWIW, Apple never promised to make FaceTime Open Source; what they said was that they were going to openly publish the protocol. I'm rather cheesed that never happened as well, but they never promised to open their source code to FaceTime.

On the other hand, Webkit is a huge OSS project, which is used by a variety of products and companies, and which has a lot of non-Apple/non-Webkit contributors. Indeed, if not for WebKit, there wouldn't be Google Chrome. CUPS is, of course, the print subsystem used by virtually every Linux distro.

Those are the projects you need to judge Apple's OSS track record on.

Yaz

That's a pretty dumb rationalization.

First off, a lot of people in this world live in climates that reach above 38C/100F. It's hardly uncommon around the equatorial zone for summers to reach into the 40's (C). 45C isn't unheard of in tropical areas, and that's over 110F. So already, your rationalization fails.

Pray tell, at what temperature do you have to worry about freezing hazards in Fahrenheit? Freezing temperatures are very important to know about as a human being; your chances of survival around or below them goes down pretty quickly in the outdoors. That's easy to discern in Celsius -- 0C is the freezing point of water at STP pretty much by definition. Anything above that, water is in liquid form. Anything below that, water is in solid form. That is important for knowing whether you can get your boat on the lake, if your water pump is going to be damaged, if your crops are going to die, if you need a heavier set of clothes, or if you need to put the snow tires on your car.

With Celsius, you don't even have to care about the range -- unless you're a climate scientist, the range is meaningless to most people. The most important idea that needs to be conveyed is where temperature hazards typically occur, and for humans the most important of these on earth is freezing. Everything with a plus in front of it has water as liquid in increasing temperature, and everything with a minus in front of it has water (be it ice, snow, or whatever) as a solid in decreasing temperature. That's only two states you really need to typically be aware of, as opposed to a range that isn't really hinged to anything at all.

Yaz

What's 1/5th of a metre? 20cm. What's 1/5th of a yard? Uh....

(Likewise ad-nauseum for any fractional multiple of 5. I hear 10 is a pretty common number, for example...)

Yaz

Some thoughts:

Wired Networking: Wireless can never touch the bandwidth, latency, or collision handling of wired networking. Provide wired access for all stationary devices, and use wireless only for those devices that are mobile or wireless-only by design (laptops, tablets, phones, WiFi lightbulbs, etc.). As much as possible, avoid wireless for things like smart TVs, set-top boxes, game consoles, etc. The more devices you have on wireless, they less bandwidth is going to be available to any one device. Unless you're going to invest in some pretty expensive networking gear, I'd stick with Cat 5e or Cat 6 cabling for now (Cat 7 is budget isn't an issue), however, ensure you use some form of wiring duct behind the walls: should the day come when you can reasonably wire everything with fibre, it will be a whole lot easier to pull it through wiring duct than it is to remove all your walls.

Geothermal Heating/Cooling: Again, if you're not constrained by budget, invest in a Geothermal system for your heating and cooling. This often needs to be done rather early in the house design/build phase (due to the need to dig deep holes into the ground), but once in place you'll have nearly free heat in the winter and cooling in the summer (usually you just need to pay for enough electricity to run a heat pump and a fan, which is negligible). I'm fortunate enough to live in a home with community geothermal, and the system has been flawless for us (albeit not as cheap as a DIY system, as the community treats the turmoil energy as a utility. Still cheaper than the alternatives, however).

Solar: Even if you don't plan on installing a solar system (ha!) right away, I suppose you could at least get the basic wiring done, such that when it is time to install such a system you already have a suitable location for the banks of batteries (if you're building from scratch, this could be part of a custom utility room designed for this purpose), plus the necessary wiring between that location and your rooftop panels. That way you're future-proofed, and the rest would pretty much be plug-and-play.

Yaz

Look, if you're going to do an interview, please try to stay on topic. You don't need to veer off into a discussion about some local wing restaurant, or some long extended rant about your local ISP choices, and how you decided to pick one versus the other.

Nobody watches, listens to, or (in my case) reads an interview to see what the interviewer has to say about random topics. They watch/listen/read the interview to see what the interviewee has to say about the topic on hand.

Maybe I read too much into the transcript, but it seemed too much of the time SJVN was just saying "Yeah", "Right", or "Got it" -- when what he really meant was "Can we get back to the part of the interview process where you ask me questions on the subject at hand"?

That interview transcript is five minutes of my life I'll never get back.

Yaz

What is the goal of this program? "Tech skills" covers a whole lot of ground, from office-drone skills to systems administration skills to web layout to SEO-type skills to basic Internet use to actual Computer Science.

Knowing what your goals are for your students certainly influences the answers your going to get. Do you just want them to have basic Internet fluency? Do you want to prep them for typical (non technical) office jobs? Becoming digital publishers? Setting up networks? Creating their own robots? Writing programs?

Answering this question is really your first step. Figure out which goals you feel are important to your students based on their own personal goals, and work from there. The rest should fall our pretty naturally.

Yaz

Or they're legacy tools. There are a large number of such tools out there that do various jobs, where having an unnecessary BOM is a liability.

If you're compiling for some legacy embedded hardware, for example, I have little doubt that its compiler would choke on BOM characters, and you may not have access to the source to fix it. And just because YOU don't need or use such tools hardly means that nobody out there does.

Yaz