156 karma · joined March 5, 2017
The same biological impulse fuels the rampant nepotism and open corruption we seem to selectively whinge about online these days.
Yet another bait and switch plays out - build clout on the goodwill of open source and execute the plan at the opportune moment.
I may understand the decision but I sure as hell don't respect it - cashing out and prioritizing your family, a very human thing to do, at a glance it almost even seems noble.
Any chance you would be willing to share the source code?
Playing on fear instead of the bright future you are opening up for us all is not the feeling I would want to leave the public with
this appears to be source available not open source
Kubernetes for sure. When anyone asks for a good place to get started with understanding k8s - I tell them the docs should be all you need, then go get hands on.
The stuff is world class.
I think opening up just enough to enable this effort also serves as some good nerd marketing for Apple. This race keeps the m1 in the news regularly, giving hope to those who want a low-power and performant ARM machine that wouldn't otherwise consider an apple machine.
The power of pardon simply further reduces the trust and legitimacy of the executive branch. At least for humans it should be revoked, I think we can still trust the presidency with the power to pardon turkeys.
Really excited to see brave adding native IPFS support, though I would hope the team could start dedicating some cycles to some of these core features that firefox has over them.
Occupation is already expensive and essentially temporary. Look at the situation in Afghanistan, the US invades and occupies the country. As they begin to withdraw, territory is taken back by the Taliban and warlords, they simply bide their time and wait for an opportunity to return.
An armed populace changes the math around occupation and engaging in violence. Of course this also leads to other oppressive mechanisms like propaganda and manufacturing concent, but at least people aren't dying. Its a step in the right direction.
Consider a treaty organization organized against a hypothetical enemy. If the adversary succeeds in corrupting and neutralizing one of the member states, that is significantly less damaging than if it were a centralized command that was corrupted.
It increases the cost dramatically to neutralize the treaty organization, and the threat to the system is easily and publicly recognized. As opposed to the slow and eventually catastrophic corruption of a centralized command.
Especially with the rhetoric today about creeping fascism, we should recognize that all authorities have the potential to become corrupt and oppressive. We should ensure proper checks against that and consider the potential consequences before implementing centralized services. Efficiency and cost effectiveness should not be the only consideration.
For instance, you might think that there are no potential downsides to a centralized welfare system. However what happens if those benefits are provided only to people of specific ideologies or races? What if it becomes contingent on giving up your biometric data or subject to drug testing as we have already seen in many areas of the US? Maybe we should consider the potential consequences of centralizing essential support structures and social safety nets.
From the SFLC Guide:
"The Corresponding Source definition – both in GPLv2 and GPLv3 – has not been typically read to include the compiler itself, but rather things like makefiles, build scripts, and packaging scripts."
These are not provided with the source code, and they claim the distributed binaries are licensed under the GPL. How is this correct if they do not satisfy the 4 freedoms?
They distribute packages for Linux distro's, where the GPL is listed as the license for the package, instead they should be listed as custom or proprietary.
Emby markets itself as an open source competitor to Plex, however the binaries they distribute are not reproducible using the code published in the repository. Despite multiple requests for the build scripts for the dotnet core version of Emby, the core developer Luke states "we are currently not publishing the build process for it, but don't worry, we will be doing .net core-based packages for all of the popular distros."[0]
The GPL requires the release of not just source code, but build scripts and supporting materials, outlined here in the SFLC's "A Practical Guide to GPL Compliance", sections 3.3, 3.4, 4.2.3. [1]
The core development team has been made aware of this, but is still refusing to make the build scripts available for the currently distributed version of Emby. Neither have they relicensed the project, despite all current contributions being covered under a CLA. This constitutes a willful and deliberate violation of the GPLv2.
[0] https://emby.media/community/index.php?/topic/51614-instruct...
[1] https://www.softwarefreedom.org/resources/2008/compliance-gu...
This modernization initiative is an opportunity to set a standard of OSS software in the USG. It would be disappointing to see this pass, securing another round of lock-in.
From the local devserver instructions: >gcloud components update
Looks like there isn't?