Absolutely, though the biggest problems are the walled gardens. Personal pads are a thing -- the various assistants from google, ms, and apple will already do things like take reminders in the form of "remind me to x at y time" or "remind me to z when I'm at w". However, sharing those notes in a reasonable way still isn't a thing as far as I can tell.
There are a number of affiliate marketing companies who will "revoke" an account, but make no effort to keep bad actors from opening new accounts, make it as hard as possible to report affiliates using malicious tactics, etc. Once you start getting into the lowest tiers of banner sellers you start seeing a lot of real skeezy moves.
Rolling out an IPv4 only stack right now is debt. IPv6 has finally hit the point where there's no longer an if portion to the question, but rather a when. Every server rolled out in an IPv4 only setup, every service built, etc, is one more potentially service-interrupting area that will have to be changed when port your stack to IPv6. If you're young and small, starting as IPv6 native means that the next few years you'll have an advantage over your competitors because they'll be thinking migrations while you're thinking about growing your business.
I always found piping other devices into the speakers a bit more interesting. Mostly noise, but just enough order to occasionally give interesting bits and pieces for your brain to catch on and try to parse.
There are people who will run rm -rf / on a box they're in the process of decommissioning it to see what stuff breaks when. Was a bit more fun in the good ol' days when more stuff was statically linked, but it's always bound to give a few surprises, like when running it on certain UEFI systems [1].
I'm surprised that no one has linked to http://opencores.org/ opencores yet. They've got a ton of vhdl code under various open licenses. The project's been around since forever and is probably a good place to start if you're curious about fpga programming.
No. The only external addressing is through QSPI0, and that only has one chip select line hooked to it. They do make small amounts -- 512k -- of SPI RAM, but that on its own would make the chip boot process interesting.
Keep in mind that the Voyager probes weren't designed to go as fast as possible, they were designed to do planetary surveying while taking advantage of a rather favorable set of planetary alignments [1]. They could have been set on a much faster course if we were just concerned about getting them as far out into space as fast as possible. Voyager 1, for example, had its path altered away from Pluto to do a more in-depth survey of Titan.
Regardless, using planets to help speed things is just good sense. Think of going on a long trip in a car. You don't hook a trailer full of all the fuel you'll need to get to your destination, you stop at gas stations along the way. Using planets is a lot like that.
In my opinion, this is getting rid of a minor historical relic, instead of the major relic of Linux booting. That ugly hack known as initramfs should have been obsoleted at least ten years ago. It was useful back when you had to worry about keeping all your boot files below the 2gb mark on a disk, but these days, all it does is create a second, ephemeral, userland in a more difficult to debug container. Put the various boot binaries into /bin and /sbin, statically linked, and completely visible to even the running system. Cleaning relics should start with getting rid of entire filesystems that just make it harder to administer a system.
If an application is making a request it hasn't marked as being one it is going to make, then chances are, there is a big problem that needs dealt with. In such a situation, crashing as soon as possible means that there's a better chance that all of the relevant data is there to pore through. If you just deny the call, then it could be many hundred of functions later, possibly with relevant data being freed up, and your job of picking through your program's entrails becomes all the more difficult.
Yes, but there are ways to prevent most memory corruption bugs, even, if you're using an OS with a non-terrible malloc implementation. The gnu malloc that most people know is a terrible antiquity that should have been replaced decades ago -- mallocs like OpenBSD's make a lot of memory corruption bugs a lot harder to exploit.
I think software like LLVM, PostgreSQL, Xorg, Hadoop, etc have shown that you don't need a radical copyleft to push forward free software. You need something better than exists elsewhere, and this kind of behavior from Stallman holds back free software out of fear of bogeymen.
The WSJ is owned by News Corp, the same company that owns Fox News. So this is probably not plagarizing, just a company printing an article in their various holdings.
For corporate accounts, I want the various cloud services to use systems that have been around since forever and a day. I want to be able to use systems like Kerberos to give Google Apps a service ticket so I can manage passwords on my server, with google only getting what user has successfully logged in. The cloud has set us backwards in single sign on, since everyone wants to be the gatekeeper.
It's 8 years old. That's not a young project. Even a project like this that's 2-3 years old should have significantly better documentation. Bad documentation in any project should be treated as a bug.
This feels very rough around the edges, especially for a project with several releases. The documentation is very uneven and sparse, with certain sections like accounting, administration, etc having no documentation at all. Security is suspect even out of the box, with demo users added by default. Other problems are that you need to restart the server if you add a language package, a short support cycle -- two years is a tiny length of time for things like health care, synchronization is not real-time, etc. Yes, it's interesting in that it is open source, but I would very much not want to have to support this in production, it's just too admin and user unfriendly.
Intel's mobile processors like the ones in the Macbook Pro support up to 64 megs of ram. Their ultra low power cpus only support 16 gigs, but the line in question goes up to 64, even with ddr3l ram.
That seems to have gotten better of late, as more systems use ECC sodimms. Poking around seems to suggest a price difference of $5-$10 a stick, and that's pretty constant regardless of memory size.
The bend radius of a cable is all but universally at least 5-10 times the width of a cable. It's pretty safe to say that a bend radius of one, like this enclosure has, is out of spec.
Look for right angle usb connectors. They're pretty useful when you're dealing with size constraints like this. I'm honestly kind of surprised that Western Digital didn't have a supplier that you could call up, custom cables seem like a natural thing for them.
Interesting project. Though first thing I'd say would be that this seems like something that would be a natural for a touch screen. Given you're going to be pulling most of the info from bar codes, you're not going to be typing very long/often, and a keyboard would be added clutter for the majority of the time.
Extended stay hotels for the kind of purposes you described already exist. They're essentially a small studio, with a kitchenette, are rented by the week, are larger than a normal hotel room, and have the personnel to ensure safety. The problem with zoning and having hotels in fun residential neighborhoods is that there often isn't the kind of civic infrastructure needed to support such things. Ability to ensure people adhere to noise ordinances, police officers, etc, are all issues that hotels have and need to be planned for.
There's a difference. Something tells me that the original poster isn't someone who is leaving with just the shirt on his back and a letter from his brother.
Pretty well. Sony's porting of AVX, for example is pretty nice, there's a good performance boost in hand there. ARM's also made some substantial improvements to LLVM, in fact dumping their old proprietary compiler for one built around LLVM. Neither of these things would have likely happened if the two projects in question had been GPL-encumbered.
A lot of projects have multiple documents that need to be discussed. There could be a spreadsheet, a few word documents and a powerpoint presentation being discussed. These things are rarely created in a vacuum, so adding a communication facility that can pull up all these things seamlessly makes sharing and discussing that much easier.