wakeupcall

I rarely edit videos, so my needs are very basic.

I tested a few such as openshot, flowblade, ... about 10 months ago.

flowblade has the best UI IMHO (more streamlined), but it was annoyingly restrictive for quick edits such as opening a clip, apply just a trim and maybe add 1 filter (usually crop).

It also wasn't very stable.

I ended up with shotcut for most of my needs. It's very flexible and has a good balance in ui/features: intuitive enough that I had to spend zero time learning it, yet has more than what I will ever need. Although it's not as smooth performance-wise as flowblade. It never crashed on me yet.

I didn't like the UI of openshot, but this is a subjective thing. Felt space-wasting and oversimplified, which might be a plus to some. It also did crash a lot for me.

I use avidemux a lot for cuts. It's the fastest editor for this by FAR. UI is minimal. I would say underrated, although it's a pretty well-known tool, just in a different class (not a NLE).

I was a big fan of "cinelerra" some years ago. It's blazingly fast, but very restrictive in the formats it accepts, which is why I stopped using it. I mostly cut random videos coming from random cameras/phones/etc, so I value free-form over standardized workflows.

Don't forget Blender. For some more complex stuff, I successfully used blender's NLE to track/mask clips. Worked perfectly, absolutely stable even for complex videos, although it needed slight more RTFM than the other options and noticeably heaver in terms of system requirements.

Usetnet was (technically still is) essentially decentralized text-only reddit, with an open protocol and a client you can choose. You can post/read on a global network. The problem is that very few groups are still active and probably dying.

Back in the day ISPs would give you an email account, some static web space accessible via FTP and access to the local NNTP (usenet) server as standard, which is why it was popular. usenet servers were peered with each other, sharing a large global namespace (servers could have local-only groups too, but that's a detail).

At the beginning, most of the online discussions happened there.

As open-source development grew, the main issue was that creating and getting approval for a group was bureaucratic/complicated and slow. As this was global and automatically peered, there was also a "minimum" number of requests to be eligible. For this reason, small groups started to move to mailing lists instead which didn't require special approval and became the new de-facto standard.

For a long time, bi-directional nntp<>mailing list software was standard for large lists. nntp clients were always designed to work with huge amount of messages efficiently compared to mail clients. I was following hundreds of groups at the time, and I still consider nntp fantastic from the user perspective.

Spam and trolls were another problem with such a public global network. Policing was hard. This is just a very short summary (it ignores completely the problem of piracy/warez and the binary split..)

Open mailing lists often have public archives, for example https://www.mail-archive.com/. Many lists are subscribed to multiple public archives.

Those archives are often searchable on their own platforms, and are indexed by regular search engines too.

Now about mailing lists created using the google "groups" platform itself, is a different story. Does google index it's own group archives? No idea. Those were _already_ horrible to look at before and I've subscribed most of the ones I follow to other public archives to get something usable.

I get >50% of my spam from legitimate hosts such as gmail and yahoo, which tick all the spf/dkim/dmark boxes.

spf/dkim/dmark helps with phishing/forgery, it does little to nothing for spam, even though this policy change makes it look like it's connected.

If I send spam through gmail, the spam is "authenticated".

spammers were among the first to implement these in an attempt to get higher score in spam filters. For quite a while dkim was positively correlated with spammyness for me.

Meanwhile.. does google even respond postmaster@ or abuse@ requests?

You don't necessarily need rain exposure. When I'm actively hiking, and especially during colder conditions, heavy condensation forms on the surface of the phone directly in the pocket. This is more frequent on sport jackets, which are designed to release internal humidity/sweat faster.

On a hiking trip.

> considering that AMD officially stopped updating drivers for Vega GPUs which are still being sold in products today(!)

This happens waaaaaaay to often in hw/embedded :(.

My experience in embedded is that usually you have two teams: lead "next-gen" product team, working from the prototype to the first shipping release where things start to barely work. This is then moved to "support" team, which will try to punch and kick things around with half the required knowledge until it's somewhat usable.

But as soon as the product cycle shifts to new gen hw with a different codebase, you're out of luck.

The dynamics in this are not so simple, but the net result is that you frequently end up with product still being produced/sold where you effectively only get tech support at best, without real fixes (hw/sw).

Range is an issue for me. I commute by public transport or bike. I only use the car for relatively long weekend trips (3/4 hours, 300+km).

For these trips, stopping halfway for charging makes no sense: I don't want to add another 30m to the trip. At the destination there is generally no charging infrastructure. If there was, that would be the only point I would consider for charging.

Charging infrastructure is still underdeveloped. I see many parking spaces converted to EV charging where the electricity cost is often double of your house utility cost, to the point that almost noone charges in such places if they can avoid. The utter nonsense of the app requirements for every single charging place.

Renting a car here is just a PITA. Go to the rental place, for which I need a car or public transport, waste 30 to 60m to get paperworks signed and car checked. I considered selling my car and just renting to get rid of the maintenance, but it turns out it's cheaper to get a used car like I do if you do at least one of such trips per month.

On top of this, EVs are still too expensive. I never bought new cars in the first place, so I'll be looking at EVs when the used marked starts to fill up with something at the same cost level of used ICE, factoring for the battery degradation.

People mention ICE maintenance, but honestly in my last 2 ICE cars, the engine was never a problem. It's usually everything else that starts breaking too often, requiring too much maintenance.

I was running FF (and netscape before that) on such machines, and they were about the worst possible program to run. My memory of browsers of the era was slow, buggy, and bloated. It was barely usable because the connection speed was by far the biggest bottleneck.

I was using dillo heavily at the time, when we didn't mind differences in rendering. After that I switched to konqueror. As the dhtml/js craze exploded, I caved in to ff when more often than not the websites didn't load or work as expected.

I checked for a specific default value (server-generated), so having no-value or a random value both wouldn't work.

It is pretty effective in most cases at evading most bots and dumb attempts, but it's also trivial to defeat if you're being targeted.

It only worked for so long. I had spammers post with the hidden field after being targeted.

I then switched the field to a hashed simple time-based value, to which they responded to by just fetching the page to get the value, and posting it back.

The posted content was often in two categories: links with stuffed keywords, or some common framework exploit (generally fetching a remote resource to test for exploitability).

While marginally entertaining in the beginning, it's just a waste of time unless you want to create some form of engagement within a blog..

I'm using earlyoom on desktop, systemd-oomd on servers.

Due to cgroupv2, systemd-oomd tends to kill entire process groups instead of a single run-away process [1]. It's perfect for servers where almost every process is part of a system service already.

For desktop usage I found this behavior unacceptable. I would sometimes get my entire X session killed when trying something dumb (which is the reason I run such a daemon in the first place), or my editor when spawning a helper subprocess...

earlyoom was the simplest daemon of the bunch I tried, and worked out of the box without special configuration.

[1] Or at least this was the state ~1yr ago.

I used to have comments and a xapian index/engine on my website, something I wish every website would have. To share my experience, I eventually removed both.

The xapian index was both faster, more accurate and up to date than any public search engine. Nobody besides myself ever used it, often returning from a google site: search instead.

Things change if you have the wiki as a personal information repository and use search yourself, as the OP points out. I still have that, but I keep this private as I also index other private stuff and can't make the two separate.

And because I have a local mirror of the archive anyway, I'm often faster grepping than using search (it's just not big enough).

I also had fully open/anonymous comments. As you might expect, this gets spam almost instantly nowadays. I switched those behind a login wall, but I realized after a few years that I wouldn't create an account on a random website myself just to post a comment. For anything more involved than a quick comment I just dropped an email to the author[1].

Right now I fear that under GDPR those public comments would just be a liability.

[1] if the author is kind enough to do so instead of dropping a twitter handle...

Agree. Shorter lines are more readable the same way narrow paragraphs in multi-column layouts are more readable, as it's easier to follow to the next line.

I'm not strict on the 80 column rule. Readability for code is a balance in intent for me first and foremost, but I also do try to keep lengths close to it.

I used to follow 2 source files side-by-side easily on a 16:10 monitor. I'm struggling to do that on my 16:9 now due to how long the lines are on my current codebase with a regular editor.

Comparisons are hourly occurrences for me. Long lines require scrolling or word-wrapping, either of which is just horrific. If I try the same on github, which wastes even more horizontal space, two source files are barely fitting side-by-side even with 80 columns.

I'm kind of surprised authors writing these long lines, which also will review those long lines in the future, and not put off by the inconvenience they're doing to themselves.

I went from "c++ fondness" to "c++ distaste" over the years. The newest c++ standards fix a lot of issues, but at the same time increase complexity. The backwards-compatibility nature is the classic double-edged sword. If we could avoid it, c++ would be at least significantly nicer (not really less complex).

That being said, a good team using a dab of c++ will beat "high quality C" any time of the year for me. Getting away from the preprocessor alone is huuuuuuuge. Everybody complains about memory safety, and the truth is that with even the dumbest string/buffer class it's actually pretty trivial to do the right thing. c++ _does_ really fix most of the c issues IMHO.

A big problem IMHO is that we "learned" to use c++ properly late. The newest standard revisions came late. The feature abuse it receives is still somewhat rampant, and yes a newcomer to c++ would probably find a use for every single feature in a simple usage scenario.

Reading large c++ codebases is hard due to the intermixing of old/new and simply different styles. It has a huge cognitive load, and that is my primary reason for the growing distaste: I want code to be clear and coherent. I can take the complexity if that's used consistently, but it can change massively between even just PARTS of a project.

At least where I shop, on a shelf if a product itself is smaller, more rows of them are used to that the space on the shelf is roughly the same, even though each row might not be stocked to the full depth of the shelf.

In most cases at least. Upper/lower rows are generally where you can find smaller/niche products are more random on that front.

Like the article explains, the shelf placement has in most cases been negotiated and/or maximized for profit. The screens will not help: I expect them doing exactly the same: scale products to subtly promote/demote depending on agreements.

They will do this in addition to what is currently being already done, so it's likely a net loss for consumers.

It's pretty easy to see why this behavior can come from programs that's don't use any standard OS toolkits, but go for custom or cross-platform solutions:

- show the tooltip - rely on move events on the main window to hide it

the move events are usually received only when the window is visible (and focused depending on the os), unless you take extra measures to grab the pointer and/or listen on global events, which involves more trickery to work right.

It's the classic scenario where a decent system toolkit has this figured out and solved for you, while doing the same by hand looks somewhat easy and normally works 95% of the time, but fails in odd ways and drives your power users crazy.

Driving UIs heavily by keyboard and shortcut is the sure-way to hit that remaining 5% all the damn time nowdays...

When google first appeared it was a revolution compared to everything else. If you expect this kind of difference, none of the alternative search engines come close.

If you are looking for big search engines, there aren't many really, I strongly believe you should give them all a shot and just alternate between them.

The biggest takeaway from this is that google isn't massively better than the worst alternative anymore and it sticks mostly due to recognition.

Did you watch the video, or is this a rhetorical response? Spoiler: it's about the conflict of interests in google search.

> PS I was reading (sceptically) 'google search is broken' already for a year or so in HN comments and have to admit I believe it now.

Even ignoring results, mainstream started to notice a while ago. Perhaps the biggest social proof at large is when it is shown distilled as comedy and people can laugh about it:

https://www.youtube.com/watch?v=NT7_SxJ3oSI

This new pricing scheme made me switch.

I still think though that in many countries it's still high.

At least from my friend group, <5$/mo is the price where most would stop "thinking about it" and just subscribe to try the service after a friend recommendation. You would probably retain most users that would otherwise never have tried it in the first place. I rely on search for work daily, and I want to support non-ad-supported business, so I'm biased. If most users don't really reach the original 1000q/mo, then more regular "non-power" users could offset the cost. Or maybe that's already factored in the current pricing.

Either way, I did enjoy kagi quite a bit on the first beta, so I knew exactly what I was in for. But if I would have subscribed as a test with the 100 initial queries I don't think I would have got attached to it. It took me a while to trust the result and compare it with other search engines to get a feeling for the service.

What's amazing here is how google did this essentially to themselves by degrading their own products to the point that existing users started to look at alternatives.

From by my own experience, you'll have to review/test the boring task from a one-time contributor, which is also not fun. You don't need to do that as often if the contributor is going to stay, but you're not attracting this sort of contributions with bounties.

The last point is also similar. If I get a significant contribution in area where I'm not competent, I might take it, but is it going to maintain or fix problems to it in the long term? I'd rather not include a feature which I know I can't maintain long term.

That's a very good point. If I look at my android experience, two major updates is the limit I would _want_ to update to. On devices where I could push the limits with lineage/cyanogenos, I could perhaps extend this to 3, being pretty apparent you're sacrificing speed for security at that point.

I hope they're going for a different track record.

I would definitely reposition the thumb cluster on the KA to be slightly lower (no more than 1cm lower really), however I didn't find this to be a problem for me.

I rest my hands with the pinky/thumb at about 15' (that is, the hand is is not with the palm flat but at about 45" compared to the keyboard). If I extend pinky and thumb, they're naturally on the same plane.

If I could tent the halves though that 1cm of difference would be nice.

On the kinesis I can hit comfortably ctrl+alt + "=" (and pretty much any other key on either half) with thumb+pinky, on both halves. Holding shift is also entirely possible with pinky or ring, even in combination with ctrl/alt/ctrl+alt and while typing with the remaining 3 fingers.

Seems a stupid thing to do when written, and maybe it is, but hey .. emacs, and I'm doing it with ease actually. I normally chord the modifiers with one hand and type with the other, but if there's a weird combination I'll just do it with a single hand too.

I could definitely 3d-print an entire glove80 mock if I found a model.

For a long time I've been pondering about just 3d-printing a modified dacytl to fit my own preferences, but it's one of those things I wish to just pay for, have some QC without wasting time, and be done.

As a general question to anybody that used the Kinesis Advantage and switched to the Glove80: how's the thumb cluster?

The double-length keys for bk/delete/enter/space allows a lot of vertical travel freedom on the hand. Instead of flexing the fingers I can just move the whole hand down and hit the lower row _very_ comfortably while not having to worry about the thumb at all.

I've mocked a few pieces of paper to advantage with the shape of the glove80 cluster and I really can't decide if that's good or bad. While the inner thumb keys of the advantage are pretty far from the key wells, the most important modifiers are all closer compared to the glove80.

Trying it on the mockup, the glove80 cluster placement forces my hand on a higher position and requires the thumb to stretch more.

I've been looking at the advantage 360 and I don't like the complete removal of the Fn row, while at the same time I also hate the old Fn keys on the advantage. The glove80 layout is really nice, but I find the thumb cluster of the advantage to be pretty darn good.

My impression for the popularity of the 75% form factor is due to laptops and people being accustomed to never have used the "missing" keys in the first place. A tell-tale is that default layout even for thinkpads is to set the Fn row to media keys by default... An increasingly smaller number of people use them, despite being a row of freely remappable keys right _there_.

What I've seen happen though is that especially on linux you need two-modifier combos (ctrl-shift/ctrl-alt) to perform what you could have done with a single Fn keystroke. Or burn a few extra keys and increase complexity with layers. I went this route a decade ago, and I'm not a fan personally. Removing the Fn row saves 2cm of vertical space from your desk. I see it as completely pointless, even if you never use the Fn keys.

And I don't buy the "reduced finger travel" argument either. Holding the modifiers in weird positions to access an extra layer is usually worse than a more spacious keyboard where your hands can be kept further apart and require less chording.

But yeah... I commented on another thread on keyboards, and the current keyboard craze is mostly about customization and looks, and very little about the actual typing experience IMHO (there are exceptions of course..).

I was working on web maps before google maps steamrolled (effectively killed) the competition. The big thing for us was that we couldn't compete with the storage and licensing requirements for satellite imagery. I suspect it was the same for other local competitors at the time: our local data was objectively better, but google's was just sexier, and you couldn't compete with free.

I've long since switched fields, but the irony is that the company I was working for survived and I heard maps for various business use is now much more expensive than our offer used to be and several large clients eventually switched back.

As a user, I loved maps when it came out. The pre-rendered tiled maps were clean and fast. The web UI was clean and responsive. Streetview was (and still is) absolutely mind boggling. Heck, I even applied to work for google maps at the time.

Nowdays maps is an absolute shitshow. I find it utterly unusable for almost any purpose except for streetview, which is the only reason I still know how it looks like.

If you're referring to the "mechanical keyboard" and similar subreddit trends, it's pretty obvious that the fascination is in the DIY and styling aspect.

It's amazing how many switches you can find today, mostly boring variations of the mx types where people post minutes-long videos of sound and smoothness when lubed.

And how it does rainbow. This is clearly what sells.

Ergonomic keyboards are a completely different market. You can't review an ergo keyboard in 5 minutes, or 5 days. The effort required to learn, and then judge the aspect of a different layout is much, much harder and time consuming. I'd argue it takes months by my own experience.

Ergonomic also means something different to each of us. For people coming in with RSI or other issues, there's no single "best" solution.

What I'm quite happy with though is that this keyboard craze has still increased the number of alternative/ergonomic layouts (and somewhat lowered the price) anyway.

Working offline is perfectly doable. I've grown not to rely on connectivity when I was living in a rural area with spotty/slow 3g connectivity at best.

Not relying on network connectivity in my entire pipeline is still today a big discriminator in the stack I choose.

The biggest downside was, and still is, documentation. I had a script that scavenged the installed packages and downloaded all relevant documentation packages automatically, along with a local indexing service (I'm still using and recommend "recoll").

There is a humongous gap between libc/posix (anything instantly accessible with "man" with stunning quality) and pretty much everything else. Even python, which has a decent "online" (built-in) reference, is not as convenient and easily searchable when looking at the html manual itself.

A local search index doesn't have the inference power of something like google to point you to the right example you're looking for something in cppreference.

And once you pass the top 10 best documented packages you have on system, you realize how downright bad everything else is documented and how much you rely on the search engine to fill the gaps from unofficial sources.

For me at least, documentation was always THE problem.