thatsaguy · HackerTrans

vor 7 Jahrendiscuss

I'm not sure I'd dismiss the risk so much. With burn temperatures reaching 600C, nearby electrolytes being vented also resulting in smaller burst explosions, difficulty in suppressing the fire, cars with other flammable products nearby and the toxicity of some formulations?

thatsaguy

vor 7 Jahrendiscuss

What I get though is that ICEs might be subject to more stringent regulation at least for charging in the future.

At least in EU, cars with a compressed fuel tank (hydrogen, GPL or methane) cannot be parked in a closed or underground parking lot for one safety reason: risk of explosion. The risk is pretty low, and if you have such a tank you're also subjected to scheduled regular inspections and replacement of the tank, but you still cannot park underground. Not many people are aware or respect this limit, thanks to the fact that it's not easy to distinguish a car which has a dual fuel option.

Now imagine a lithium fire in a garage (maybe... your garage?).

thatsaguy

vor 7 Jahrendiscuss

Incidentally, SSDs also benefit from read and write locality. Although there's no seek penalty, there's still a large benefit from dispatching multiple reads and writes from/to the same cell. You get those for free by trying to minimize "seeks", although the underlying logic behind this optimization is simpler.

thatsaguy

vor 7 Jahrendiscuss

I have nothing against sixel, of course. But to put things in perspective, Sixel support by itself is not great. Definitely more supported than iterm's, but not universal.

But when developing a new program that wants to output graphics to the terminal, OSC1337 is damn easy (you'll likely not need any new dependency or image handling routines), while for sixel you'd probably need libsixel or write your own encoder.

As a developer, I vastly edge towards iterm's handling. (and to be honest, as a user as well. png encoding is faster too!)

thatsaguy

vor 7 Jahrendiscuss

Sixel is nice (and I use it all the time), but we do have better nowadays.

iterm's image handling [1] is superior: it just encodes a modern and more efficient image format and sends it inbound to be decoded by the terminal. png was always at least equal if not more efficient than sixel at indexed colormaps. You can send jpegs for drastically more efficient true-color images.

The "OSC1337" is not unique to iterm. mlterm also supports it, and I do remember a few others as well. You can use "ranger" to have image previews on a remote server without having to jump through hoops.

[1] https://iterm2.com/documentation-images.html

thatsaguy

vor 7 Jahrendiscuss

I've been using FF with resistFinterprinting on since it was available. Letterboxing does break a lot of websites and apps, sometimes making them unusable due to incorrect positioning and scaling of the elements.

thatsaguy

vor 7 Jahrendiscuss

This is pretty common, and systems like SA do this for you by batching responses and calculating a score.

I found this to be pretty much worthless if you already have greylisting, even for high-quality curated lists such as spamhaus SBL/XBL.

thatsaguy

vor 7 Jahrendiscuss

I'm not contradicting his assertions. I actually confirm them: there is now a lot of spam coming from gmail. He's clearly one of the reasons.

thatsaguy

vor 7 Jahrendiscuss

I don't know about other servers, but on the systems I manage gmail itself is the #1 spam source since 3 years at the very least. If you look at my previous posts, I commented on this two days ago.

There's literally _Zero_ value in DNSBL/DKIM/SPF because of this. Email sent from reputable sources is actually _more_ likely to be spam than small mail servers.

Content-based filters are the only thing that work against this sort of spam.

thatsaguy

vor 7 Jahrendiscuss

Address reputation was always big, even back then.

In the last years though, I cannot really recommend to use any of the DNSBL anymore. I've encountered more cases where legitimate servers were blocked due to netblock vicinity or indeed previous ownership than actual spam issues.

Greylisting will still catch dynamic allocations almost as effectively, while you won't reject legitimate mail due to server and/or DNSBL issues.

thatsaguy

vor 7 Jahrendiscuss

From my perspective (~500 employee mail server), greylisting had a much larger impact at the time, thanks to the spambots/viruses attempting direct connection to mail servers. Extremely effective, zero false positives, much lighter on resources. I did use both, of course, so that I could keep a record of how effective the systems were.

Today the situation has flipped. Most of the spam we get is coming from authoritative servers (ie: gmail, yahoo, etc), making stuff like SPF/DKIM/etc next to worthless from a spam perspective (it's still marginally useful for forgeries), while bayes (or in general, trainable) filters are essentially the only thing that can differentiate it reliably.

With a modern setup, you can basically next to zero spam and no false positives. In fact, honest email marketing (ie: mailing lists you've actually subscribed to) are from my experience the only thing that throws these filters off.

thatsaguy

vor 7 Jahrendiscuss

But do these operators actually perform deterministically? Does the page actually contains a match for my terms? In my experience, this has become less and less true.

The first obvious mistake in the list is that google doesn't default to AND anymore since ages. A list of two terms will be some random combination of one of them, maybe both of them, and occasionally none (and no, this doesn't happen due to fetch/indexing lag or stemming or autocorrect).

To get true inclusive searches you need to quote the terms, individually. People keep pointing at verbatim search, but verbatim performs phrase search, which is not what you want in most of the cases.

DDG suffers from the same. I curse them both. I've used some js to quote individual terms before performing the search to get back useful searches for technical terms.

But really, the number of times I now get pages which do not contain the exact terms I'm looking for is subjectively increasing.

thatsaguy

vor 7 Jahrendiscuss

I also second PragmataPro. I've been using it for 5+ years now. The ligatures are fully optional, and the font comes in several variants for software that doesn't allow to select features.

It's a slab serif, condensed. You have to like the style. Some people prefer the opposite (wide with ample interline spacing).

It packs quite some columns on the screen while still being perfectly readable and basically every glypth is hand-tuned for small pixel sizes. There's not much else comparable designed with that amount of care.

The closest font on a stylistic basis I've seen is Iosevka.

thatsaguy

vor 8 Jahrendiscuss

Fusion 360 has the better pricing model, it's that simple. 500$ is not too expensive even for a hobbist: you'll likely spend more on consumables in a single year. And there's simply nothing else of that value for that price point. There are no OSS solutions that can offer reasonable CAD design yet.

I'm not a fan of Fusion: it's UI is not really well designed. It's slow and clunky. It forces "cloud" on your throat for ABSOLUTELY NO GOOD REASON. Seriously: wtf? I frequently need to work offline, and Fusion doesn't really seem to get out of my way.

Onshape, which is 100% web based, is better is several ways: it's actually faster to booth, which is scary! (not in everything, but for most things it is!). Starts in a 1/10 of the time. The interface is much more streamlined and efficient to work with. For my purposes, Onshape is only lacking in "variable" management (there's no substitute for a simple spreadsheet here -- even FreeCAD is superior in this regard).

Am I recommending Onshape? No. I hate cloud-based solutions. The lock-in is absolutely obvious here: if you're offline you're doomed. Import/export is read-only.

However, for ~500$ a year, with Fusion you get a complete CAD/CAM solution with decent CFD. Onshape starts at 1000$+ and only gets you a (good) CAD system, and you still need $$$ more for CAM.

If you're starting, Fusion is the better deal. It's that simple.

I'm not sure why Onshape is squandering the opportunity here to provide a slightly cheaper offering to promote their solution. Their CAD is good, but not good enough for the fusion offer. They could capture a nice maker segment if they provided a slightly cheaper solution.

Now, why not FreeCAD? The problem I see is that FreeCAD is quite a bit behind to be usable for day-to-day work. I use it for toy projects, and it's pretty limiting by itself. I wrote and recommended before that FreeCAD starts to really shine only when combined with Cadquery or OpenSCAD. With parametric sketching, "visual" interfaces only get you so far. Cadquery gives FreeCAD a considerable edge for complex designs.

The problem though still stands: even if you just start with 3D printing you realize consumables and electricity are not a zero cost anymore. 3D printing and hardware design in general is expensive. Investing some money into 3D design tools is logical, but you want something that works reasonably for your hardware. It's a chicken-and-egg problem. I'm a developer, there's no way I could work on a 3D CAD in the size of FreeCAD in my spare time and get anywhere useful.

All being said, FreeCAD 0.17 passed SolveSpace for all my purposes this year, which is a great achievement. At some point FreeCAD will become viable enough and will in turn start to attract enough money to staff full-time people.

thatsaguy

vor 8 Jahrendiscuss

I use FreeCAD whenever possible. It's a very capable cad, despite the limitations.

My main complaint is that history management in FreeCAD is poor, and the ability to assemble parts is very, very limited currently.

That is: create a sketch, extrude, and fillet 2 edges at random. FreeCAD seem to use some incredibly naive edge enumeration technique, which breaks instantly as soon as you add/remove edges from the underlying sketch. This makes design revisions almost impossible currently, which is the primary reason you use a parametric cad for.

OpenCascade in itself is not as bad as people make it to be. It's a bit buggy, but not drastically more so than fusion 360. In fact, you learn to work around most geometric kernel issues in any parametric cad with time. All of them have bugs and corner cases. OCC itself has never been a limitation for most of my designs.

FreeCAD combined with CadQuery is immensely more powerful than most commercial offerings I've tried. I dream of being able to interleave CadQuery and FreeCAD sketches at any point in history to prototype!

thatsaguy

vor 8 Jahrendiscuss

More probably because editors with a steep learning curve (emacs/vi) tend to select for people more willing to invest effort in learning.

The same can be said for Go when Go was relatively new. You learnt [Go^H^Hnew thing] because you thought it was interesting or wanted to play, not because you had to.

As a secondary effect, editors in the likes of emacs/vi require a different mindset compared to an IDE when programming on large projects. There's no question that all IDEs in general have an huge advantage for "all things discoverability" (from project layout to built-in doc).

I personally rely much more on documentation and memorization than autocomplete, despite autocomplete-like extensions being available to both emacs/vi for quite a while. There's a steep hill to climb when approaching large, new codebases when working this way, and it definitely doesn't pay off for quick fixes.

That being said, I used anything from IntelliJ, NetBeans to VSCode and when thinking about "good editor" the first thing that comes to mind is: zero latency. If your computer is slower than you, there's a problem somewhere.

thatsaguy

vor 8 Jahrendiscuss

Nim is actually great. The syntax is streamlined and you can pick it up in a few hours if you have some basic experience with python.

Because it's effectively a transpiler and it's way less opinionated than (say) Rust, I managed to use nim in embedded controllers without any special support from the compiler.

Nim suffers because it doesn't have the big push of a corporation such as Mozilla behind.

thatsaguy

vor 8 Jahrendiscuss

I'm currently using mutt with "getmail" (which does support IDLE), which I can recommend -- it's an excellent client, but only if you're fine with tweaking.

I used TB until two years ago, but I gave up with it's unfixed bugs and quirks. I do prefer graphical clients, but not if they are clunky or buggy.

I used Silpheed and Claws for years, but Silpheed locks (or used to lock) the UI during fetch (unacceptable IMHO) while Claws has some critical bugs in the filter/rule logic that made me lose mail in several occasions by refiling into the wrong folder while processing a lot of messages. If you arent't a heavy filter user you might be fine with it though, I think Claws gets a lot of things right.

KMail wasn't bad when I used it, but it was too long ago to make an honest comment today.

thatsaguy

vor 8 Jahrendiscuss

IDLE is an old extension. Unfortunately Thunderbird is a crappy client.

thatsaguy

vor 8 Jahrendiscuss

The "new microsoft" provides a baseline operating system riddled with spyware, an update system that takes over the control of your system and pushes random content to your drive and a closed-as-ever groupware suite. Nothing has really changed except some developer allure, which seems to be working.

But I don't want to be tracked when I paid for their stuff. I want control over my system. And from a developer perspective, I'm still 1000% more productive on any nix based system where the tooling is (and has generally always been) years ahead.

There are very few areas where I need to use windows, and it's only due to vendor lock-in. Embedded development tools and professional RE tools are stronger on windows, sadly.

comments