bsdubernerd

Yes, but it's kind of anticlimactic isn't it? If the issue was SMTP/protocol, then spam within the gmail network wouldn't exist. But it's not the case.

The main issue is that email is designed to accept messages from strangers you don't know. Because you want that, and it's a core feature. You will have spam on any network where there this is possible.

If you remove the ability to being contacted from strangers, then email would stop being useful.

You don't even need to change the protocol if you wanted zero spam.

I have one email address where I accept only PGP-signed messages I trust with my known keychain, and discard everything else. I can publish this address anywhere. No spam gets through. There are a couple of other ways you could do this with fancy header tagging if you really wanted to, it's besides the point. The issue goes away as soon as you ignore the first contact problem.

> I want Gentoo that has been prepared as if the user just recompiled every goddamned program that makes up the core os, build desiderata and all waiting for me to make another change.

You likely don't want that. You can expect compiled objects to be in a 10:1 ratio compared to the final build size. Rust is closer to 30:1 in my experience so far. Then you have projects that vastly exceed that.

As a dev, I'm constantly struggling with disk space with just the projects I'm working on.

This doesn't even begin to handle the issue of contained/reproducible builds.

And with things such as LTO, you might be waiting at the "linking" step way longer than what you might think.

I don't think you realize how GOOD gentoo makes it already, considering all the variables in question. You can rebuild and patch the entire system, from start to finish, with a single command. Take a moment to appreciate this fact alone.

This is the job of your linux distribution: it's not just a pile of packages. It includes the bridges required to rebuild each package for the infrastructure of the distribution.

If you really want to have everything rebuilding from source at your fingertips, you could already do that with gentoo and similar. Patching upstream sources and rebuilding is pretty trivial there if that's your thing. There are more to choose from.

You probably won't be having the build infrastructure of all your packages "ready" all the time though, and things are taking a turn to the worse due to dependency bundling where each package has it's own independent copy.

I think the article misses the mark. The #1 problem is spam, but spam is mostly a social issue, not a technical one.

Case in point: 90%+ of my spam is currently delivered by google. Either using fake accounts and/or hacked ones.

That spam passes _all_ the technical solutions we have put in place today: SPF/DKIM/DMARC. Sure, the SMTP protocol isn't that great in today's light, but you think changing the protocol would solve it?

Say hello to whatsapp spam, facebook's messenger spam, and so on...

Fully agree. There's a lot of value in providing a change summary which is _not_ tied to development history.

Even as a dev, I usually don't care about your PRs. I'm pretty sure there will never be a 1:1 PR/feature history. Keeping the commit history in the repository clean must be useful for the developer (for example, to possibly revert atomically a change), not for the end user.

Do you find more informative the Linus changelog between kernel releases listing a stack of PRs, or the nicer summary provided by kernelnewbies (and others) showing the prominent new features so you can drill down later?

Git has very nice release notes. The language used in the release notes is completely different from commit history.

It's a very nice gesture to write good release notes.

It doesn't take long to do, and I find it beneficial for PRs that include notable changes that should get into the release notes also include a new line in there. It doesn't need to be perfect (surely it will change before being finalized), but it serves as a landmark for the final edit.

I love/hate info. On one side, info can be more than a manual page, and contain _usable_ references. I suppose you know about the "all in one" manpage bundles such as ffmpeg-all and zshall which are there just so you can search?

Yeah..

On the other side, "info cp" didn't bring up the _reference_ of cp for a frickin' loooong time. It was a usability nightmare for that reason, and that reason alone. Had it worked the way it's working now: bringing you to the command reference first, but allow to search the entire manual scope at once (and WORKING references!), I would have been SOLD from the first moment.

The fixed-width format is the last thing I wished would be removed. I disabled catpath and have full-width manpages, but I cannot do the same with info as the text is pre-formatted.

I had a lot of other big technic sets at the time. I remember this one, and I also remember my parents telling me it was too expensive.

They were not joking.

Not too long ago I wanted to gift a technic set and I was shocked at the prices. The fact that most modern sets also use a lot of custom parts was also something that goes against the lego mindset IMHO.

It would still be something that I would totally buy for my children, but not as a gift for somebody else.

The counterpoint is that it's now actually useless to craft a query that tries to match exact terms, because there's this extra layer on top of it.

So you might be lucky if the inferred intent of the engine was correct, but good luck steering it away. It doesn't help pretty much all query logic operators are merely hints nowadays, more often ignored than not.

I very much preferred a dumber engine for this reason, since it was way easier to search precisely and avoid SEO, even as the SEO game changed.

I'm also using a local searx instance now. I'm not terribly happy about it as bing/ddg also have very similar issues, so searching for exact terms still doesn't work the way it should. But it's much easier to blackhole SEO silos, pre-filter queries NOT matching my exact queries, as well as yielding more obscure content.

Oh I'm fully aware. This scene has been going on far longer than the current wave of mechanical keyboard craze (and it often doesn't emphasize switches as much either). I consider the two groups completely distinct.

As other posters mentioned, the recent "mechanical keyboard" subculture is all about show and boasting. It's not a surprise it seem to have boomed with gaming rigs and streaming channels.

The keyboard in these circles is all about status, not function. If anything, I would compare it to "dubious" car mods like "cambered wheels".

Due to RSI I tried dozens of keyboards over the years. When I see these new keyboards being sold at these prices, especially the mechanical ones marketed with "improved layouts" and ergonomics, I have to laugh.

There's genuine difference between the various switch types, and I totally believe that for some people the acoustic feedback can be a valid alternative to the haptic one. Physical feedback while typing can really help. However it's clear to me most of these people are not really trying to solve an issue when you see reviews of switching performance after lubing...

I have to agree.

I'm currently using tridactyl, but due to the webext limitations it's far from what even vimfx could do in terms of consistency.

On top of all you said, when you realize not only the browser has inconsistent shortcuts, but a webpage has the right to steal your keyboard shortcut and break the extension itself ...

Every time I use '/' and either it doesn't work because I'm in a field where the extension doesn't have access or in a website where it's redirected to the USELESS site search, I truly get mad.

I'm not even sure why I insist in trying, since there's no clear intention to allow such customization to ever work consistently in the future.

Ideas as in "search some term, get a not-even-vaguely-related picture collection you cannot see unless you log in"? Or the "ideas" that also happen to hide where that very idea came from?

Pinterest is scourge for a text search engine. It's also scourge for an IMAGE search engine, because it's just hiding the real source.

Pinterest is in the top 10 websites I would blacklist from search results.

I do the same for projects I'm looking at, and I'm on linux. Gives a good understanding of the thing you're looking at. There are many things you can tell by looking at the build process.

There are some things I do not agree with the author though.

Pure make: I think it's refreshing to see, nowdays. Many autotools projects do not do ANY configuration, and could actually use just make in most cases. But the authors just jumped at the "autoconf/cmake" bandwagon, because they probably were never familiar with make, or just want to follow conventions (which is ok, I guess).

Fixing a make build is leaps and bounds easier than to fix compared to cmake or autotools. If you follow the "standard" C environment variable conventions a makefile can be extremely portable (I've written stuff myself supporting osx/linux/bsd/irix/aix for several years). Vanilla make doesn't support variant builds, but if you ever need that (and are willing to believe that make is not rotten as many people seem to suggest), I suggest you look at makepp.

There's no date on the article, but a common incumbent to cmake these days is meson. As a dev, I'm still conflicted between these two: meson has a superior syntax and less baggage, but everything else seems inferior to me at the moment, especially the documentation.

Building from source also gives you an idea of how the author is managing dependencies, which ones were chosen, and so on.

A big one for me is how I still consider a package with two external (that you have to build yourself), robust dependencies much better than 20 smaller cargo-managed crates that require 300mb to build, or ~100 packages pulled by tox when you actually _need_ to contribute to the python package...

This is great way to weed off between multiple candidate projects when you have the luxury of doing so.

For starters, chording requires significantly more hand coordination than a normal keyboard. This is a significant show-stopper for many.

Think about all the people you know that still have to look at the keyboard to type, that type just using one finger and one hand at a time, that still hunt for common symbols. None of this would work with a chording keyboard.

Unless you're transcribing, typing is not usually a limiting factor. This is especially true for programmers. For example I'm using three different keyboard layouts due to the commonality of languages around here and as a result I keep doing typos due to switching. I never bothered on improving because it's simply not a limiting factor.

What's even more ironic to me, is that we would have much simpler improvements to keyboards to make RSI and typing more efficient with minimal impact (I'm thinking ortholinear layouts - not chording!), but nobody really seems to care.

Not strictly everything, but this rings very true to me, especially for the front page.

I'm a bit surprised by this. 2mm pitches are well printable at .2, although I usually don't use the stand ANSI/DIN profiles, but limit the overhang profiles manually depending on the material (from 45 up to 70, really) to improve them. Still, at 2mm, this shouldn't be necessary.

Maybe the slicer you're using is doing something odd.

Keep in mind that if the filament string looks pulled in a full thread, a toothed thread with the same settings will be even weaker. In such cases it will change the result to localized sagging areas, where the structural element is just the start/end of each tooth.

A screw, even plastic one, will easily self-thread into the thin amount of plastic remaining, but that doesn't mean that the thread works as intended structurally.

If you have issues with smaller threads my reccomendation is to print an undersized cylinder and use a tap for best results, or just slightly undersize the hole and self-thread instead.

Magit is not particularly fast on *nix either. Most of the UI operates on buffers which are prepared infrequently, so the latency doesn't have significant impact. This is a very good UI design for magit itself, since staying within emacs provides bigger benefits in most cases.

However, my own cited example about browsing history and blames is one case where I cannot just stomach the subpar efficiency. Tig also runs git as a subprocess, but every view is truly incremental and you can scroll through any buffer in any view and there's absolutely zero delay. Night and day even when comparing emacs with JIT.

Like for magit, tig has one keystroke shortcuts that make sense (which IMHO is pretty common on good TUI programs) and can perform many git operations directly from the spot you're looking at.

I also consider the visual space usage in tig to be much more efficient as well. Especially the blame view, which I find still wasteful in all modes compared to tig's. I frequently use a customized vc-annotate instead.

Magit hooks also considerably slow down operations on remote files, which can be quite annoying if you don't actively need to use git while editing.

Don't get me wrong - I like magit. But like org-mode, I don't get the glorification it gets.

For the sake of discussion, can we get some contrarian views?

I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here.

Tig for example is so much faster for history and blame perusal that I find it faster to keep it open in another terminal and just switch to it.

Altenatives? Contrarians?

I assume this happens on very small threads and/or with thick layers?

I print both depending on size, and a full thread is usually more self-supported, not _less_, while printing faster to booth. Toothed threads tend to suffer from curling more easily when comparing at the same overhang slope, and are weaker structurally.

I'm using toothed threads for larger threads to save on time/material usually, or oddball constraints.

I can see why you would get the effect you're describing, but this would only happen if you're printing with insufficient Z resolution in order to support the overhang of the thread. I cannot see how a toothed thread would improve in such a scenario.

I don't see a command-line or daemon backend. Not really comparable, even if I happened to use kde.

syncthing is excellent for sharing also between groups.

I wish it worked better for occasional file sharing (for example to transfer files between phone/pc). I don't want to keep it running in the background - just sucks too much power, and on the phone I never need to keep other stuff synched. But the time it takes for the first connect to happen after starting it can be in the order if minutes on a known network, dozens of minutes if not. Not usable for this purpose.

The android client is also not very well thought out. You cannot "share to syncthing" until it's active, so if you want to put a file for sharing until your network connectivity is up, you can't. You have to start it, share, then shut it down. If you want to do that on an unknown network you didn't whitelist, you have to whitelist the network as well. Kind of pointless. You'd think you can also start it when it prompts you to change the settings, but this also doesn't work.

I ended up disabling all these advanced settings, as they clearly end-up being an hindrance. I just start it manually and quit it, kind of defeating the entire purpose of them.

openSCAD has a few operators to highlight/isolate the current syntax block. Have you ever used those?

Working on a project using openscad is not that different than using other cad programs: you should split your model into "modules"/functions and use composition effectively.

I generally find nodal interfaces quite inefficient in general and scale very poorly in every context I've seen them.

The biggest problem with openSCAD for me is that there's no way to "measure" in the preview window. As in: just pick two faces and give me the parallel distance and/or vertex-to-vertex distance. I don't care about precision of the preview, let me double-check!

You have no idea how often this comes up when connecting multiple parts. Computing the distance manually, while possible, is such a nuisance. Every respectable CAD program gives you a distance when clicking on things for this reason. Somehow FreeCAD made this quite unnecessarily clunky that I have to rely on addons and openscad is missing it completely :(

Yes. I couldn't. The alternatives were worse. I need remote banking (travelling too frequently). No alternative allowed plain login without a second factor.

I've seen other banks here _charging_ for the hardware OTP dongle separately. The yearly price of the dongle was more expensive than simply getting another crap phone and installing the app.

This is not exclusive to Dell.

Many laptop makers started to intentionally disable S3 for the "enhanced" S2. This was/is true of Lenovo as well: for roughly 6 months S3 was disabled completely on the then-new 3rd generation Yoga X1 laptops and Carbon counterparts. It was re-enabled thanks to linux user's uproar under the "legacy sleep mode" umbrella.

Why would you go as far as disabling it, is beyond me. S3 is the sleep mode I expect on a laptop. S2 sounds useful for tablet/phone behavior.

Hibernation doesn't of course suffer from this issue, and I never experienced this on any laptop with S3 sleep.

Of course, if you shut down your laptop and put it immediately in a bag, temperature will raise temporarily even if the system is off due to the inability to dissipate heat. You should be aware of this, and avoid immediately bagging the laptop just after rebuilding the kernel ;)

I wish I could upvote you more.

There's nothing about "freedom" in this post, it's all about developer's convenience. It's easier to keep local changes and push them later if the upstream is not changing much. If your upstream is a moving target, doing anything but upstream-first is only making it worse for yourself in the long run.

Nothing to add regarding bootloader locking and safetynet on top. I don't want multiple phones (I actually don't want one), but I was forced to to install my banking app 2nd factor app. I cannot root it, I cannot remove GA, safetynet prevents me to reflash it with something else, even though I theoretically can.

The best part is that at some point you can choose between:

- old/vulnerable/unpatchable android with safetynet => banking apps will be happy to work with it

or

- new fixed android which is safer, but won't pass safetynet

Yeah.. "safety".

What about lldb? Has anybody had extensive experience with both to say anything about the actual debugging experience? Does it offer anything more than just "infrastructure"?

Which is actually the case. In fact, audio is the best examples where everything can plug into almost everything. padsp (if I'm not mistaken - not at the prompt right now) does just that.

The OS is all about resource sharing and allow a minimum common level of interoperability.

Smalltalk can provide a storage abstraction, but to interoperate with other things it needs to be able to save data in a way that can be loaded back into your Java program.

OSes can provide you with the desired abstraction level.

You could stop at the block layer, which many DBs can take advantage of, but that won't help your Java and Smalltalk program work together easily. A filesystem is a common abstraction which should provided by someone.

Your example about the graphics stack is no different, the problem is that various components of the system are not "shared" in the same way all the time. The actual low-level abstraction of the GPU being provided to you by the kernel has more complexity today than what it had years ago in order to allow virtualization and compartmentalization of graphics memory. This wasn't needed some years ago, as it was assumed X11 was the only program to ever going to access the framebuffer, and would allow any single program using GL to trash the entire GPU.

What has been simplified is the user-level facing code, so that you can more precisely control allocation of the resources. Akin to the page-level memory allocation support we always had. This was done to allow /some/ programs (3d engines) to push the hardware to the limits (I'm relatively sad the GL1.x is "deprecated" - I still consider it to be an excellent API for prototyping and what would be 90%+ of applications).

Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. And it's interesting because the effort went in and out of the kernel a couple of times. Describing the evolution of OSS/ALSA in linux/freebsd would be too long, however we now have very fat daemons sitting in front of the HW just for resource sharing.

This sounds problematic from a debugger perspective if the function does any sort of side effect, and I'd consider this a bug as well.

In fact, I'd probably argue that causing user-code to run at debug time is not a good idea even if the function is guaranteed to be side-effect free.

I'm not sure why companies think that restricting usage this way improves their product in any way. You need a different build, and an online account to do something that should require neither.

Heck, I can only partially understand the "click many times over crap" to enable experimental features, which should have been _enough_ to begin with (and certainly not a requirement in a beta build). How many hoops do I need?

After reading this, I was really /hoping/ Fennec would remove the requirement of having a Mozilla account, but no, you still need to create an account and an useless "collection".

TBH I use (and ever used) Firefox just due to the available extensions. The value proposition has decreased quite a bit with recent FF versions, and on Android uBlock is pretty much the only reason I stick to it.

I wish I had more alternatives, because clearly the browser duopoly isn't working.