Malaysia has only itself to blame.
35 karma · joined July 2, 2024
Due to unethical mafioso tactics of some of the "big tech" companies, commercial entities are not named.
Some time around mid-2012, at two different higher end of software development firms, the target system for 90+% of clients was some open source language such as Java, Node, Python, Scala, Ruby, targeting some Linux. At one of these our DevOps went ahead without even really being asked to at least monitor that our builds ran successfully on BSD and illumos, and occasionally patch as necessary.
For clients asking us to work on .NET there was a premium charge and ZeroMQ was used to "bridge" .NET with something else. The only clients that successfully insisted on pure .NET did so by paying a bigger premium charge.
By 2018, we were doing heavy sideways discounts on ".NET core for Linux" in the form of heavy premium charges for the alternative.
> Good luck trying to get on the corp network [with] ClownStrike Falcon crap.
This is what a virtual machine is for.
mhmm...
And Windows doesn't run at all on 99.99999% of them, and never will.
> Buy a consumer Walmart PC running Windows and it is expected to be plug and play with nearly any graphics card, USB scanner, printer, etc
There isn't a single graphics card you can buy in a store today that doesn't work with Linux. In the mid-2000s there were USB scanners and printers that didn't work with Linux but now finding a USB scanner or printer that doesn't work with Linux is extremely rare.
This argument about compatibility is an extremely stupid argument.
Put simply, yes. If you read open OpenBSD's website what philosophies and practices drive how the OpenBSD project is run, you'll have an idea.
I know of a very small airport where what is displayed over the HDMI part is essentially Firefox at fullscreen with powersaving disabled so the screen does not blank. Some of them are Intel NUC, some of them are Raspberry Pi with HSM in a box. These devices basically "boot to Firefox" with relevant credentials read off internal TPM/HSM.
Those among airport staff who do not know how to use a computer at all can get them working by just plugging them in.
> Most people know how to use a windows computer.
They know enough to open a browser.
> Most IT desktop support knows how to use and manage windows.
They know how to cope with Windows, at best.
> Finding someone who knows a BSD is not easy.
BSD is everywhere and in far more places than Windows, like almost every car sold after 2014. But you never ever see BSD because it's already-working with nothing for the end customer to do.
I was personally involved in a meeting where my firm's leadership advised a client who did fire their CTO and a bunch of other people for what was ultimately putting what they thought were smart career moves over their actual responsibilities.
Unfortunately, as you did just point out, the CEO, other execs, and board are often just as incompetent as the CTO/CISO who have such shit-brained mindset.
See what was already written in the comment you replied to:
We do not ship Linux kernels that contain drivers that cause crashes.
Yes there are tons of Linux images out there built by stupid people and thus crash all the time, which is not Linux' fault but the fault of those stupid people. As already should have been clear enough, or so I thought in the comment you replied t: my company doesn't ship stupid images built by stupid people.
I work for a company that provides secure endpoints that are Linux based (and can also run Windows apps without issue). We do not ship Linux kernels that contain drivers that cause crashes.
Per our IT patterns and also mandated by our commercial contracts, we investigate any crashes that occur. Over the last five years, not a single crash has been caused by a device driver.
We also will never have a use for the style of security software that Crowdstrike has. Our security stack is proactively preventative, not reactive or looking for "anomalies".
So this "it absolutely would [happen on Linux]", should have an asterisk, a huge one glaring like the sun, and without said asterisk is inaccurate at an extreme.
For Crowdstrike customers foolish enough to be Crowdstrike customers, yes. The nature of the software pipelines for Red Hat and Debian are very friendly to continuous integration and testing in a way that Windows can not be, at least not without Microsoft sharing source code, which to be fair Crowdstrke is one of the companies they may actually do that with.
Nonetheless, other vendors can choose to do proper cicd with Red Hat and Debian without asking Microsoft.
Running Windows on bare-metal was always obviously very stupid. The consequences of such stupidity are just being felt now.
Good luck enforcing that.
This, 1,000%
[*] we charge a hefty premium to manage third party OS in a sideways way by offering a 75% discount on our endpoint OS, with exception to special and authentic cases (some 3D CAD or other).
Three important points of context to highlight here:
0.] We don't hire for "butts in seats", we hire for aptitude and/or talent then also culture very carefully and if someone isn't vibing, isn't "getting it", we fire very fast (locking them out with the same stack we use to operate customers' devices).
1.] We don't use Git in the typical pedestrian centralized way (ie GitLab), Git is of a distributed and we use Git as such in an approach that gracefully is combined with other things that, like Git, do their one small thing and do it right. Our approach has been described as "nirvana for security and compliance" and is still considered somewhat novel. We would call this "bespoke", but the use of this approach has been uniform in each place.
2.] We consider our Git approach with SaltStack something that any entry-level SysAdmin or even IT Ops should be able to wrap their head around. Salt obviates a lot of Python we might otherwise write. The end customer has "engineers" who do write in some interpreted languages, maybe some languages on JVM and some C#, but they don't write software in a sane way, so they pay for our clicky clicky to talk to our API for what we have done. Ultimately, the customer doesn't really "do computer" (even though they try), they are users, "power users" at best (which is kind of worse actually). Open Source is about *source code* ie software, which is the part we are good at and the customer is not.
3.] Without the existing wealth of open source software, we would not even attempt to be playing the same ballpark we are now. Context number zero is more strongly why we are much more confident with what we have than anything in the whitelabel-option Managed Services Provider space, but this context number three is also a big part.
The BeyondCorp / ZeroTrust in place does all of its "smart" like time-of-day or some statistic/heuristic at layer-4 (TLS). The layer-3 is there too because defense-in-depth. I know we have something on the roadmap to add more smarts to the Wireguard pieces (I'd have to ask someone). The non-management Wireguard tunnels, the ones for "app", don't come up without TPM unbothered and a user's hardware key being involved. We haven't yet seen a BeyondCorp / ZeroTrust suite from a vendor we found compelling or "we really want X feature they have" that we can't easily (and more quickly than a sales cycle) do ourselves with our model.
Background:
The customer had existing IPAM, but it was too much of a mess. The kinds of customers that don't have clean IPAM also don't have IPv6. So we went ahead and used some of the IPv6 that our corp has from ARIN with proper agreements in place with customer to make using our IPv6 space "okay" and endpoints do 4in6 to reach customers' existing IPv4 subnets (mostly RFC1918).
Every device in our purview is notated as a YAML versioned by Git for SaltStack to do whatever on the device. Each machine has a unique id, similar to the /etc/machine-id concept, with data for that machine expressed as SaltStack Pillar.
Typical incident:
Suppose machine morty.foo.baz.example.net is stolen from a user's car. Upon awareness of the incident the key "status" in the YAML for morty is updated to have value "stolen" added to change management (Git). A look up is done on every public key used by the Wireguard peer named Morty, and every device that uses any of those public keys gets poked to apply the new data expressed as Salt.
Remediation:
On another device running Wireguard named Rick, the public key for Morty is now expressed in a new way by Salt Pillar and the relevant Salt State has "file.absent" for the public key. For the public key Salt already has "onchanges" to "service reload wireguard-something" (reload, not restart) via init script which changes what needs to be changed and only what needs to be changed.
https://docs.saltproject.io/en/latest/topics/pillar/index.html#pillar
https://docs.saltproject.io/en/latest/ref/states/requisites.html#onchanges
https://docs.saltproject.io/en/latest/ref/states/all/salt.states.file.html#salt.states.file.absentThis is not to disregard the meaningful thought and work that goes into the proprietary layers built on top of the open source codebases. But, we should all acknowledge that without those extremely high quality open source codebases, most SaaS wouldn't exist in the first place.
Thus far the only cases where the MS Office users don't gradually slide into the gravity of an OnlyOffice service on private silicon is the heavy MS Excel (desktop) users who are of a very relevant (CFO, accounting) yet relatively small cohort.