> If I were an asshole, I would have trained them poorly and drug it out.
That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know.
The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.
> having used gerrit 10 years ago there's nothing about github's PRs that I like more, today.
I love patch stack review systems. I understand why they're not more popular, they can be a bit harder to understand and more work to craft, but it's just a wonderful experience once you get them. Making my reviews work in phabricator made my patchsets in general so much better, and making my patchsets better have improved my communication skills.
Labor in the sense that it's abuse is exploitative. It's extractive. Child labor seeks to use the children for the profit of the adults running the operation. There's certainly _work_ that children can grow from doing. There's certainly work that looks like labor that children grow from doing. They just actually have to grow from doing it, and that must be the motivation. If you start making money off of children, then your care for the limits of the "healthy dose" starts diminishing real fast.
Yep this, children are the most vulnerable class. If the capitalist system had the power it had in the past, we'd just throw them into factories at age 6 or 7 again and damn them to the terrible life of a factory worker with no rights so some adult can have slightly more.
You are correct that caring is important - but it also isn't your responsibility at the end of the day. If you don't care you're doing it wrong - if you let it eat you up inside whenever anything goes wrong you're also doing it wrong.
Work-life balance is mostly talked about in terms of time commitments but there is also an emotional commitment you need to balance. It's unhealthy to be too far in either extreme and, especially folks that are naturally empathetic, should be more wary of falling into the trap of overinvesting in a workplace and suffering mentally for it.
You can access files that contain certificate information (on any OS), but you can't access individual certificates as their own object. In your output, you're listing files that may or may not contain valid certificate information.
The difference is similar to being able to do 'ls /usr/bin/ls' vs 'ls /proc/12345/...' , the first is a literal file listing, the second is a way to access/manipulate the ls process (supposedly pid 12345). In windows, certificates are not just files but parsed/processed/validated usage specific objects. The same applies on Linux but it is up to openssl, gnutls,etc... to make sense of that information. If openssl/gnutls had a VFS mount for their view of the certificates on the system (and GPG!!) that would be similar to cert:\ in powershell.
Linux lacks a lot of APIs other operating systems have and certificate management is one of them.
A Linux equivalent of listing certificates through the Windows virtual file system would be something like listing /proc/self/tls/certificates (which doesn't actually exist, of course, because Linux has decided that stuff like that is the user's problem to set up and not an OS API).
A GNU/Linux OS does not lack them. As do other OSes using Linux. Linux isn't a OS, it is a kernel. You wouldn't complain, that the NT kernel lacks a graphical file explorer.
Fair enough; the Linux kernel is arguably missing the API, but only for kTLS.
However, GNU/Linux does lack such an API. There is no standard API for listing certificates and private keys. All GNU/Linux provides is a list of files that may or may not contain one or more certificates and/or private keys that may or may not be related to each other. You have to go beyond the basic GNU parts to get to things like keychains.
This is nice! What I find hard to grapple with is, how do other concepts of the file system map to these providers, even more so to Alias, Environment, Function or Variable?
Like creating an item, deleting an item, copying an item, viewing contents and properties like permissions, size, visibility of an item?
For the Certificate provider specifically: When I think certificates and hierarchy, I think signing hierarchy of issueing certs. But this is not what is exposed here, just the structure of the OS cert store without context. and moving items has much more implications that inside a normal data folder. Thus I prefer certlm/certmgr.msc as they provide some more of it.
I _suspect_ they mean that certs imported into MMC in Windows can be accessed at magic paths, but...yeah linux can do that because it skips the step of making a magical holding area for certs.
there are magical holding areas in Linux as well, but that detail is up to TLS libraries like openssl at run-time, and hidden away from their clients. There are a myriad of ways to manage just ca certs, gnutls may not use openssl's paths, and each distro has its own idea of where the certs go. The ideal unix-y way (that windows/powershell gets) would be to mount a virtual volume for certificates where users and client apps alike can view/manipulate certificate information. If you've tried to get a internal certs working with different Linux distros/deployments you might be familiar with the headache (but a minor one I'll admit).
Not for certs specifically (that I know of) but Plan9 and it's derivaties are very hard on making everything VFS abstracted. Of course /proc , /sys and others are awesome, but there are still things that need their own FS view but are relegated to just 'files'. Like ~/.cache ~/.config and all the xdg standards. I get it, it's a standardized path and all, but what's being abstracted is here is not "data in a file" but "cache" and "configuration" (more specific), it should still be in a VFS path, but it shouldn't be a file that is exposed but an abstraction of "configuration settings" or "cache entries" backed by whatever thing you want (e.g.: redis, sqlite, s3,etc..). The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
> The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
In theory, this is what dbus is doing, but through APIs rather than arbitrary path-key-value triplets. You can run your secret manager of choice and as long as it responds to the DBUS API calls correctly, the calling application doesn't know who's managing the secrets for you. Same goes for sound, display config, and the Bluetooth API, although some are "branded" so they're not quite interchangeable as they might change on a whim.
Gnome's dconf system looks a lot like the Windows registry and thanks to the capability to add documentation directly to keys, it's also a lot easier to actually use if you're trying to configure a system.
It is unclear. Everyday I seem to read contradictory headlines about whether or not inference is profitable.
If inference has significant profitability and you're the only game in town, you could do really well.
But without regulation, as a commodity, the margin on inference approaches zero.
None of this even speaks to recouping the R&D costs it takes to stay competitive. If they're not able to pull up the ladder, these frontier model companies could have a really bad time.
I remember picking through an aerospace scrapyard in North Hollywood a decade ago with extremely-talented launch engineers (and entrepreneurs). The aim was to look at parts, measure them and figure out why they were built like they were. We looked, a little, at stuff like nozzles. But mostly we focussed on bolts, joiners, turbine blades and the like.
That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know.
The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.