I stand corrected.
I stand corrected.
1/ The Mythical Man Month was "referenced" (and mangled) about in an unrelated article by Eddy Baldry. It is he who mis-states the premise of the MMM
2/ Mythical Man Month's statement is "Adding more manpower to an already late project delays it further." This is different from the premise stated by Baldry.
3/ Anders Wallgren mentions nothing of the Mythical Man Month
4/ Wallgren actually does say that microservices, underpinning some of the arguments for DevOps, is not suitaed for all projects.
5/ The summary is a lie.
Sandstorm is a security product, so we want to address that head-on.
When you install software on Linux, no matter what package manager you use, you are giving that software permission to act as you. Most package managers will even execute scripts from the package at install time – as root. So in reality, although curl|bash looks scary, it’s really just laying bare the reality that applies to every popular package manager out there: anything you install can pwn you.
Realistically, downloading and installing software while relying on HTTPS for integrity is a widely-used practice. The web sites for Firefox, Rust, Google Chrome, and many others offer an HTTPS download as the primary installation mechanism.
Have you considered using something other than BitLocker? https://alternativeto.net/software/windows-bitlocker/?license=opensource&platform=windows
And I'm gonna say it - why not use disk-encrypted Linux and put Windows in a VM for those one or two programs that are Windows-only? This way you have full control of your system, the whole disk is encrypted, and you can stick to Windows 7...
They carve a niche, realize it's a niche, abandon it.
Then open source solutuions come in to fill the gap and i make myself use them. May the trend continue.
So two thoughts come to me after reading the summary and the comments
1/ This clearly demonstrates that Linux is the right technology to use when supporting business syetms with legacy hardware (I'll second the opinions that enterprise keeps hardware around the longest - I supported users on obsolete AS/400s which, whilst not as old as what some people here talk about, still mean we're frequently learning old technology in Support); and the point that the leadership (Linus right now, hopefully the same with whomever comes to replace him eventually!) can be more ameanable to keeping up support for old hardware is great. I dream of desktop uptake, but enterprise and research are where it's at.
2/ However I also wonder - isn't this an offshoot problem of the fact that Linux is a monolothic kernel? Can this kind of interface-specific support not be modularized? Say, an API/ABI (in-kernel)standard that allows the kernel to plough on with currently evolving requirements, whilst maintaining a stable interface for previously integrated kernel features that have been split off into modules...?
(and no, I'm not at all familiar with the ins and outs of kernel development and architecture - I just read newsposts and Wikipedia
Except that this has nothing to do with "attacks". The word "damage" is also applied to the "trust" and "credibility" of governmental institutions.
This kind of legislation would apply even if nobody died in the carrying out of the activity.
So the major players want to bring some order to the bazaar. So be it - they can try. There are small projects that will probably decide to cooperate, and will because they are a one- or two- person effort - but the projects that truly behave like a bazaar will remain as coordinated or uncoordinated as they still are.
I don't see this effort being capable of shoving an agenda down anybody's throats - if you don't care for the agenda, don't. Submit your code to the project as and when you see fit, and work on the bits you want to. If tomorrow they want to address what they see as glaring issues in GNU's netcat, they'll be able to throw resources at it collectively - but I doubt they'll be able to tap GNU's shoulder and say "hey, give us some of 'your' devs to fix this."
In the end, if the effort results in a pooled selection of developers, incentivized directly and collectively (read: employed) by the companies, to work on aspects of open source projects they have communal stake in, to common goals and specification, that is probably going to be a good thing.
If they fork any of the technologies that is fine too - that's exactly what GNU GPLv3 was meant to allow them to do. They just can't expect to fork the maintainers and community too.
If however there is a scenario in which volunteers can be coerced into their way or the highway, that scenario must be understood and countermeasures prepared by those who would stand to lose from it. Don't take it too seriously, but don't take it in any way lightly either.
From a user's perspective, three sources: the Linux Action Show podcast highlghts fun/useful items once a week.
Then there's tuxmachines.org which talks about.... well pretty much anything, you'll have to sift through the deluge...
Then just following what's generally popular, and using alternativeto.net to find open source counterparts...
In the original article an ArretSurImages.fr, the blogger details in her interview that she decided not to hire a lawyer, instead simply complied immediately and did not defend her position. She was not required by the court to remove her post, but she did so of her own accord.
A commenting lawyer interviewed for the article indicated that the case shows more the necessity of getting legal advice, rather than any evolution of rights on the Internet.
Yes it's sad that she was attacked for her criticisms, but it's sadder that she did not take responsibility, or stand her ground.
This is sounding like a LOIC - but that issues DMCA requests instead of network requests
Hm. I would say "there goes my preference for not associating my phone with an online account" but that would actually be incorrect. Though I would indeed prefer not to have to have an account to install apps.
I guess I still treat my phone like a computer in many respects and I'm trying my darndest to keep it away from any form of remote kill at all for the sake of a "no remote please" blanket stance...
Still, I'm pretty sure I prefer to be slightly on the neurotic side.
Whilst all this may be valid and true, how are we going to prevent the "wrong people" from using this kill switch? Will it be hardware based, in which case, how will we be sure it won't be triggered/used remotely if we install a different OS on the device? Or if some script kiddie found a way of activating it by exploiting an insecure app?
(new hollywood armaggedon scenario: terrorists threaten to detonante a phone bomb that would activate kill switches around the world, bringing down entire civilizations)
Yes, a technological solution might exist for the problem; question is, is this one the right one? Are we going to stop looking for alternatives?
"Trust me. I know what I'm doing." -- Sledge Hammer