Carpetsmoker

I was under the impression this was still the best way to do it for maximum compatibility ... but perhaps that character got killed in season 3 and I missed it

I don't use it at all, but others do and I think my little library is neat enough for others to benefit. Unfortunately, I can't get any of thus UMD stuff to work, so for the time being I just "window.imgzoom = function(..) { .. }" it shrug.

Yeah, the entire process of dealing with exceptions (or indeed, anything that involves human judgement) is atrocious at YouTube, and has been for many years.

jwz wrote about this years ago as well (and there are many more stories): https://www.jwz.org/blog/2014/10/youtubes-joke-of-a-fair-use...

That being said, I feel too many people fail to appreciate the problems YouTube is facing and are too quick to simply shout "censorship!"

But at least I can just download a .py file (or a bunch of files) and just import them. Perhaps the biggest frustration/pain point in this article isn't npm as such, but that you can't "just" use some JS module.

I think one difference is that this is usually abstracted to quite some degree. Most devs rarely (if ever) have to deal with C/C++ build systems, as package managers and whatnot deal with that.

For most people installing some C/C++ library it's just "apt-get install libfoo" (and maybe libfoo-dev), and they never have to deal with ninja/autotools/cmake/etc, whereas for JavaScript you directly have to deal with the tooling by using "npm install libfoo".

The same task mentioned in the article would probably be a lot easier: install package, write some code, "c++ -lfoo main.cpp".

"Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on.

The other day I wanted to publish a little script I've been maintaining for years as a module easily usable by WebPack and whatnot, and that's much easier said than done. I published it on npm and put some UMD magic thing in there, and I think it should work now ... but I'm not really sure to be honest (still need to look at this and confirm).

Just searching "publish JavaScript module" and trying to make sense of the WebPack isn't really all that helpful, not for me anyway, as I'm joining half-way through season 6.

I have no opinion on the tooling as such – I lack experience to have an informed opinion – but it sure is confusing to "quickly" do something for people who are not heavily involved in it (i.e. me)

500 hours of video is uploaded to YouTube every minute; it's impossible to moderate all of that. "Lots of users reported it in a short timespan" is a reasonable heuristic to quickly remove ISIS beheading videos and whatnot.

It's not perfect, but nothing YouTube does at this kind of scale will be.

I ran some performance/reliability benchmarks on the product I'm working on (which supports SQLite and PostgreSQL), and SQLite was about 30% faster than PostgreSQL.

This won't hold true for all use cases; one table now has 11 million rows, and I'm not sure how well SQLite would perform on that. The benchmark was very simple anyway, and it's mostly a read-only where users don't update/insert new stuff. Would be interesting to re-test all of this.

It's just easier: I won't have to split queries with 1,500 parameters in two because of some limit.

The general strategy is to create a new table, insert data from the old table, drop the old table, rename the new table, and re-create the indexes:

  create table foo2 (
   col1 int,
   col2 text
  );
  insert into foo2 sleect col1, col2 from foo;
  drop table foo;
  alter table foo2 rename to foo;
  create index on foo(col1);

See: https://www.sqlite.org/lang_altertable.html#making_other_kin...

As for the reason, see the next section on that link. It's not perfect, but it is what it is. SQLite wasn't designed to solve 100% of the use cases, and that's not a bad thing.

What other systems would you recommend?

I don't know if this is true or not, but it's besides the point; MongoDB omitted various failings from the Jepsen report to make their product look better than it actually is. This is not only unethical, but may also be illegal in various jurisdictions under false advertising laws.

Whatever failings MySQL or PostgreSQL may or may not have are not important at all here.

The article is correct in stating that PHP has moved quite a bit in the last ~10 years; even back when I was using PHP in the 5.1/5.2/5.3 days things were already steadily improving.

But ... that doesn't mean that PHP is a good language, or that people hate in PHP "just because it's cool". There are still many issues that remain. For example the very loose typing checking remains an issue and source of real bugs; e.g. a while ago a SAML library could be bypassed because it forgot to add the flag to in_array() to enable strict comparisons.

Much of the problems in PHP are with the standard library, and this is not easy to fix. Even the mysql deprecation (in favour of mysqli/PDO) took ages. I wrote a thing looking at fopen() in PHP a while ago, and I think it's a good example of the problems that remain in PHP: https://www.arp242.net/php-fopen-is-broken.html

There are still many issues with the standard library like this which are clumsy and just plain design errors, and many of them are too fundamental to work around or fix. Has PHP evolved? Sure, and that's great! But that doesn't mean it's now an especially good language. In general, I'd rather have a poor language with a good standard library than a good language with a poor standard library.

Aside: one weird thing about PHP's stdlib is that it's all written in C; I don't know any other comparable language where all of the standard library is written in C. I think this seriously hamper's the evolution of PHP's stdlib to a more modern experience.

There is no easy fix for any of this btw, because a revamping of the stdlib would likely lead to a "Python 3 scenario", so I don't blame the PHP devs for not fixing it (although I do blame them for introducing new flawed parts to the stdlib, like the whole DateTime fiasco), but that doesn't mean it's not a problem.

I suspect the dollar signs may be part of the reason of PHP's success. While it's clear for experienced programmers that "x" and "y" are variables and "foo" is a function in "x = foo(y)", for new programmers "$x = foo($y)" is probably easier to read and mentally parse.

That is my personal experience anyway, as someone whose first truly serious language was PHP 20 years ago. Maybe it was just because I was used to it (BASIC also used $), but it took me a bit to get used to the "bare" variables in Python and C back in the day.

This is actually recognized in the article itself (but who has time to read that when you can reply to just the headline and perhaps the first few paragraphs, right?)

And FOIA about the COVID-19 response are unlikely to require digging in to some archive, and are of limited use when fulfilled after it's actually over. This is what the mentioned suit is about.

I've been to 2 Go conferences myself, and had an absolutely fantastic time. Great people all-around.

But ... the online experience here is a bit different from the conference experience.

Re: point 3 the "go" tag on Stack Overflow is the worst one I know. Some very nice and helpful people, and some ... people who just love to nitpick Every. Single. Mistake. Loads of questions in the go tag getting downvoted and closed just because of that :-/

Even as someone who mostly answers questions it's frustrating.

He has touted both; e.g. https://www.youtube.com/watch?v=3GuNbGC2D_8

In-vitro results are worth following up on, but it is my understanding (as a non-expert) that it's very common that they don't pan out in actual humans. Turns out that human bodies and the way we interact with drugs are rather more complex than simple in-vitro situations.

It's really to soon to recommend either drug. Even with 0 side-effects there is a high risk of it being a massive waste of resources better spent elsewhere. This is just classic Trump afraid of being seen as not being on the top of the world in literally every situation.

Also interesting read on some more background of the drug: https://blogs.sciencemag.org/pipeline/archives/2020/03/20/ch...

All I know is what I can see from the X-Spam headers they add with that matched rules, which are SA's. FastMail has been around for ages, and I guess it's "good enough" (or at least, not "bad enough" to replace). It's not so easy to replace a tested (though imperfect) solution like SA with some new AI stuff, even of it would be better; it's all about ROI.

Also, not sure if Howard is still involved to FastMail? They sold to Opera in 2010, although they've been independent again since 2013, but it looks like the 2010 sale was the end of Howard's involvement?

Most software can be compiled with --prefix=/usr/local, and then it will store stuff in /usr/local/share, /usr/local/etc, and so forth.

In fact, /usr/local is actually the default for a lot of programs; you manually have to specifically --prefix=/usr if you want to use that.

I used to maintain a bunch of FreeBSD ports, and whenever this wasn't supported I'd send a patch upstream, which was pretty much always accepted. In a few cases: yeah, you'll have to patch the paths, which is not ideal, but it's a lot less patching than what Debian does, which often has more changes and backports security fixes etc.

> APIs forcing more convoluted authentication methods

It's not really that convoluted: it's just setting a header with a fixed token, which is actually simpler than HTTP auth.

FastMail just uses SpamAssassin btw; I'm not sure if they have any modifications, but based on the results it seems just the standard SA.

When I announced my own analytics thing here a few months ago I got quite a few signups from the HN thread, and based on the bug reports, support requests, etc quite a few of the users are just running it on their personal blog. I'm aware of some other solutions as well that aren't mentioned at all in that table.

Personally I found Matomo rather hard to use, I tried it for a while but decided that writing my own was easier than figuring out to get Matomo to do what I want (also: cheaper and easier). I think it's a good alternative for some use cases, but far from all. Related comment I left on Lobsters a few days ago: https://lobste.rs/s/cdrrty/why_you_should_stop_using_google#...

As someone who runs one of those 3rd-party analytics: the JS you add to your site is small, readable, and can be downloaded and included from your own CDN. Hell, you don't even need the script, you can just write your own (not very hard actually). I took a look at Plausible a while ago, and I think the same applies here as well.

With GA, I can do none of that; it's just a massive unreadable blob I can only load from the GA servers. I just have to trust Google doesn't do anything I don't want (including XSS, but also other issues). It's not even easy to figure out what information exactly it collects last time. It's very untransparent and un-auditable and the website equivalent of loading binary kernel blobs.

> - https://github.com/zgoat/goatcounter (Golang) (Commercial Licensed)

Small correction: it's not really "commercial licensed", it's completely Open Source/Free Software according to the OSI definition and "four freedoms", and can be used for any purpose including commercial (EUPL license, roughly similar to the AGPL).

Only the hosted goatcounter.com SaaS operates on a "free for personal use, pay for commercial use" basis, but there is nothing stopping you from running your own instance for commercial purposes.

I think I need to clarify the README on this a little bit, as I had someone else ask the same question yesterday as well :-)

Ask the former secretary of state how well that went for her.

It's not always an option, even if they can't read your email casually, your company may still have perfectly legitimate reasons to keep it under their control for reasons of auditing etc.

I agree there are certain similarities and problems in the US. But mass-censorship, concentration camps, and a true surveillance state on the level of China don't exist in the US. Some, like an expansion of the surveillance state, are plausible (maybe even likely?) in the near-future, whereas I don't see mass-censorship, concentration camps, or appointing the president for life happening any time soon.

In the Netherlands there was a court case which ruled that an employer cannot just read an employees work email, as even work-related emails are considered private information.

There are some exceptions of course: if you notify the employee and have a justified reason you can check some emails. So it's not outright forbidden. It matters a lot on the case and what you did, exactly.

I'm not aware of the situation in other countries.

(In Dutch: https://www.cnvvakmensen.nl/nextnow/blog/2016/march/mag-de-b... and https://www.sprengersadvocaten.nl/publicaties/wanneer-mag-ee...)

When people write it like that?