wyqydsyq's comments

> in this case, facial recognition tech was unreliable entirely because of the people running it.

Wrong.

In this case the facial recognition tech itself was arguably not unreliable. The human operators were the unreliable factor.

The recognition tech reliably tagged the impersonator as Ousmane exactly as it was instructed to do. The system worked exactly as intended. It is the human operator whose intention was wrong.

This has nothing to do with AI being unreliable and everything to do with the employees of this SIS company going "yep kid's black, he's the one who did it" without half a thought.

What requires them to get approval from the FAA for something outside the FAA's jurisdiction?

> I find them useful as I write code because they allow me to state my intention (in plain English), translate it to code, then compare statements and see how well I’ve achieved my goal.

IMO this is exactly what unit tests should be used for. Replace these comments with unit tests and you're doing TDD. The practical difference is by stating your intention as unit tests, you not only verify your initial implementation is correct but also that any future changes remain correct.

> All employer / employee relationships have this dynamic

Wrong, no employer relies on a newly hired employee the way they rely on a senior knowledge silo'd engineer with a decade+ of domain knowledge which they are reluctant to share. In most jobs the employee is not in a position to have that kind of bargaining leverage. That leverage is only gained by an employee either intentionally and maliciously making the codebase as esoteric and unmaintainable as possible, or poor management not planning for these risks sufficiently e.g. not hiring more staff for a legacy COBOL system team as it's members leave until there's only one guy left who understands it.

> While I think blackmail isn't an accurate description of this

I'd argue it is. You know their business depends on you as a result of you actively working to make it depend on you, you use that knowledge to leverage your position in bargaining for higher pay or to never get fired from a low-effort "cruiser" job. Essentially blackmailing the business into continuing your employment under threat of losses caused by you leaving and nobody else being able to maintain the mess you created. This is not a normal employer / employee relationship dynamic at all.

Exactly this. If you are a single point of failure knowledge silo, the business sees you as a liability since if you decide to quit, their business is then screwed. This is why turning yourself into a silo is making yourself disposable - it gives the employer a very good reason to try and find an alternative to continuing their reliance on you.

Meaning your employer now has all the more reason to replace you as soon as an opportunity presents itself

> No, you just make yourself disposable.

You might be making yourself disposable specifically in the context of your original role which you are basically making redundant by documenting and automating everything - but trust me any sensible business will want to keep a staff member who massively improved their team's productivity (by enabling them to be more independent with less silo'd knowledge) and reduced the business' risk exposure (by making potentially critical knowledge more accessible and reducing single points of failure).

Employees who try to become indesposable by turning themselves into a mega-silo of knowledge that nobody else in the org has might gain some job security in the short term but they lose out on any potential job progression.

Turning yourself into a silo like this is practically blackmailing your employer into keeping you. They might keep you employed because they need to keep their systems online, but they will also not think twice about replacing you as soon as an opportunity is presented. That is making yourself disposable.

Turning yourself into a leader who improves the outcomes of various teams in a business will not only make you indespensable, it's genuinely the best (if not the only realistic) path for an engineer to work their way up into more senior or C-suite positions.

> It's true that Apple have a better track record of keeping data private, and there's been no Cambridge Analytics style atrocities

You seem to be completely unaware of the multitude of data breaches and leaks that Apple has faced, some they've even tried to actively cover up. Apple has a very obvious track record of disregarding their customers interests in favour of trying to protect their PR. Why notify customers and address data breaches when you can cover it up and pretend to be the champions of customer privacy when announcing anti-competitive policies that gives Apple monopolies?

> If you’re looking for a way to share logic between front-end and back-end code

So... exactly like isomorphic/universal JavaScript?

What exactly is the practical benefit in this, compared to say, JS functions shared by serialising them as strings or by abstracting them into a common dependency package which can be ran both on front-end and back-end?

Most Kiwi accents I've heard noticeably pronounced other vowels as "i". e.g. "dick" instead of "deck", "tinnis" instead of "tennis"

Or if any of the students are from New Zealand

> The interesting question to me is, why is it that they are literally the ONLY large tech company that is willing to offer me this tradeoff?

Maybe other corporations consider it unethical to charge their customers a premium for a false sense of privacy and security?

> Samsung, Google, Facebook, Amazon and Microsoft don't sell privacy

And neither does Apple, they just sell you on the promise of privacy. The reality is quite far removed from the perception most customers are given by their marketing and PR campaigns.

Apple might be a bit more stringent on enforcement of data sharing with third parties compared to other large tech corps, but that doesn't magically mean your privacy is invulnerable through their devices and services.

There have been multiple cases of them being caught out being hypocritical in regards to privacy, there have been multiple data breaches of Apple services and platforms to varying degrees of severity. Since the recent Epic lawsuit, it's also been revealed that Apple decided to not notify some 150 million of their customers who were victims of a data breach.

Anyone who actually thinks Apple cares even remotely about their privacy is living in a fantasy land. Unless you think being not alerted of your personal data getting exposed in a data breach of their systems is somehow not in your privacy's best interests.

> No. It is the domain. No one else in this business has a short pronounceable *mail.com

Except for, oh, I don't know, maybe https://mail.com/ ?

> Spam filtering is a a very difficult thing to do well and Google's implementation was very good, very advanced, and trained on huge amounts of data. Something a normal person could never do on their own server

I'm sure most normal people could install SpamAssassin and configure it to use community blacklists on their Dovecot/Postfix server. It's not that hard.

I prefer to think of it as wisdom is what you know intrinsically, education is what you have learned, intelligence is your capacity for learning

Every tech company I've worked at used Linux for servers as well, however that doesn't mean I'm ignorant of the huge number of (predominantly large enterprise) corporations relying on the Windows Server stack. Also I would argue there are significantly more servers, embedded devices and especially networking infrastructure running *BSD than you give it credit for, not to mention every consumer device manufactured by Apple.

How many open source projects or tech companies can you cite using an SCM suite other than Git, except for Google which you already mentioned?

The huge disparity in usage makes it pretty clear Git is the only widely relevant SCM suite today. GitHub and GitLab are arguably the most active and central hubs of open source communities, and they're based on Git. Bitbucket discontinued Mercurial support a while ago. How many popular / impactful public code hosting repositories are primarily using SCMs other than Git? I'd be surprised if you can name a single one other than Google's now discontinued Google Code service.

> Actually, my memory is essentially that the IE team was doing decent work.

Yes for a while there they were doing a great job of implementing Microsoft's Embrace, Extend, Extinguish philosophy by intentionally avoiding web standards conformance and instead focusing on proprietary features (ActiveX plugins etc) in attempt to make IE "better" than the competition

Reddit is still accessible on mobile via browsers though, so even if Apple imposes rules on the native app it's easily worked around. AFAIK the discord webapp only works on desktop, so for iOS users wanting to access NSFW discords on their mobile device they are shit out of luck

> I had to check that this wasn't an April fool's day post. Linux powers a large proportion of servers on the internet, and has done so for a long time now. The popularity of Git is a relatively recent phenomenon.

Linux might be used for the majority of web servers, sure, however Git is used for version controlling the significant majority of software produced today. I would argue something that is used by nearly every software development team/company across the entire planet has a much greater impact than something that is used by nearly every server across the planet.

Linux also sees more heavy competition from the likes of Windows and *BSD, where git has essentially dominated it's market with things like CVS, SVN and Mercurial becoming increasingly abandoned, and only niche proprietary systems like Perforce still competing for usage

I would argue requiring your whole team to learn a new framework-specific templating language and patterns is not simple, compared to using something that is plain JS/TS which the whole team already knows. It also complicates hiring, as programmers who know JS/TS and can pick up React/Angular/etc are a dime a dozen, in contrast to trying to hire programmers to work with a niche framework which has a lot of domain specific knowledge.