I always wonder why Google didn't just keep improving/extending Hangouts. Was the codebase just unsalvageable? Was it something to do with Google's internal politics?
I think that’s one of the reasons that WPF never saw much use in terms of widely distributed desktop apps. You couldn’t assume the presence of a particular version of the framework on any given Windows install and (until now) you couldn’t bundle the framework with the app like you could with the JDK.
A lot of Windows applications built with .NET do a dependency check and launch the .NET Framework installer (often included in the installation package) if you are missing the minimum required version.
Of course, that is a system-level change, which can potentially break other applications on your machine (if they're written badly and/or poorly supported). .NET Core removes that by supporting side-by-side versions and versions packaged with the app, but it certainly wasn't critical to assume a given machine already had a .NET Framework version in question.
Honestly, with Windows 10 now including .NET Framework updates along with feature upgrades every six months, and the fact that pre-Windows 10 versions of Windows haven't that many more years to live, it feels like that advantage isn't as big as it used to be anyways.
My concern is .NET Core may lead to a lot of unnecessary software bloat. Where Windows has the current .NET Framework, but we still have to have six versions of .NET Core installed, and then half the programs on the computer don't use those and have their own bundled versions as well. I find .NET Framework already being on-system to be a big perk of writing my app with it: My software is a 7 MB file because most of the code is already built into Windows.
Right? I'm surprised at how many of the comments here seem to be about using AWS for hobby-scale stuff... I keep a Digital Ocean VPS for my personal website and OpenVPN AS and stuff like that, but anything I'm deploying for work on AWS is... either totally transient (I just need compute and enough working space to store the code I'm executing) or critically important (local storage is not sufficient, I need redundancy and shared state and lots of 9s). I can't think of many commercial use cases outside of prototypes where you'd want a bundle of compute + storage all on the same hardware.
Its like we stopped the "cattle vs pets" metaphor a bit early and some people are mad that a butcher is selling steak instead of a whole cow.
(And just for the record, my team has pretty minimal AWS usage... we're not one of the cloud kool-aid shops. We buy overflow worker server capacity on EC2 spot instances, but our primary app stack runs completely on colo'd bare metal for our day to day operations. Even on our bare metal though... individual app/worker servers are disposable and persistence is provided elsewhere)
It's funny how all these replies are almost an answer in an of themselves. You laid down a basic truth: the only thing technically distinctive about a blockchain is the trustless consensus algorithm. The rest of it is perfectly run of the mill tech. And yet the deluge of replies is completely focused on the run of the mill tech like merkle trees and distributed datastores. Some good ideas maybe but nothing to do with blockchains.
>Utility tokens exist to provide access to a good or service on a decentralized, blockchain-based network. [...] Siacoin is specifically designed as a utility token and has never been used for fundraising.
And yet it looks and behaves exactly like a speculative vehicle, just like all the other crypto coins.
I'd really like to see his proposal as something you can toggle when you navigate to someone's twitter profile, since when I do that I'm usually only interested in things they wrote themselves, not things they retweeted.
It's impossible to have full-disk encryption with that config, right? (i.e., does FileVault work for the root user?)
If you can get in from an install CD, you can reset passwords as needed.
If I were writing this patch, I'd probably check to see if the root user's password was indeed blank, but given that use of the root account only is extremely unsupported I cannot get too upset about Apple breaking that use case as long as you can get back in.
The issue wasn’t actually specific to a blank password. You could try to log in as root using any password, and as long as root had never had a password set, it would fail but set root’s password to whatever you entered.
I just installed the patch on a system where I had logged into root with a blank to confirm the issue. Root login no longer works in the unlock dialog. I didn't try a more sophisticated test.
So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.
I'm fairly confident most Mac users never enable the root account at all. We don't need to. I'm not sure people who've only used other Unix systems understand that; I didn't when I came to the Mac after using Linux and FreeBSD in the 1990s. You need an administrator account, but that's not really the same thing. I haven't had a root account enabled on a Mac in about 15 years. (Well, except for a 14 hour or so stretch from yesterday evening to this morning, between the time I enabled it with a strong password as a "fix" for this bug and the time the actual fix was pushed by Apple.)
At any rate, I'd be very surprised if there was even a single user literally locked out of their Mac because of this change. I think it'd have been better on general principle if they'd done some kind of check that boiled down to "if the root user is enabled but it doesn't have a password set, disable it, otherwise leave it enabled," but there may be perfectly valid reasons that they couldn't do that.
> So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.
It might be the only local user with a password set, with all other users coming from a remote directory service. Think university labs.
Also, you can always pardon a single incident. But Apple got so aggressive with casualties caused by their system updates that I'm really pissed off by it.
System updates regularly reset configuration to factory settings, breaking things in the progress. Note that I'm not talking about modified system files (those we expect to get reset and thus try hard not to touch) but documented configuration points.
This arrogant mindset is best described as "you surely didn't meant to deviate from our divine default settings, so let me fix that for you!".
For some files they recently started to move your modified files out of the way (creating a backup blah.conf.$(date) or whatever) before forcing the factory config anyway. Not that we need it, but it's probably all we'll ever get.
It seems like the concepts are orthogonal though. The reason powershell works is that it replaced the entire shell toolchain with object-oriented equivalents. Without that you're fundamentally limited because your inputs are still plain text, so you're still doing the equivalent of awk/sed scripts to transform text into structured data.
That aligns pretty much with my conclusion that to make an useful object shell, I'd be essentially rewriting the whole userland and probably some kernel bits too (/proc and /sys etc). So basically building a completely new OS on top of Linux kernel. I wouldn't expect such project to be very popular..
For quite a while now, I've fantasized about creating an object-oriented toy OS with an OO shell and something akin to Classic Mac OS's resource forks. As much information as possible would be stored as OO data structures in alternate file streams with native tooling to query them.
It would need to be based on Illumos and not Linux, though... IIRC, the only existing open-source filesystem that supports anything akin to a resource fork is ZFS, and the Linux kernel doesn't have the syscalls readily access it (ZFS implements extended attributes as forks, but the kernel has really tight limitations on what can be done with xattrs, much tighter than what ZFS can do).
It's just a fantasy, though, and not something I have the skills or the time to do.
There was a reddit comment I came across years ago and saved because it sums up the limitations of shell scripting so well:
I think I've just come to realize a sad fact though: processing raw text streams through mostly-regular languages is really weak. There aren't that many problems that can be solved through regular or mostly-regular languages, and not many that can be solved well by the former glued together with some Turing-complete bits in-between.
