HN user
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?
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?).
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.
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!)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
IDLE is an old extension. Unfortunately Thunderbird is a crappy client.
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.
FIY, IMAP actually allows "push messages" via the IDLE extension. If you use K9 on android, it's enabled by default. I never used gmail, but I'd be surprised if the gmail imap server didn't support it (and I would dismiss gmail entirely if it didn't).
RSS support in FF was always poor, but that was often enough to preview a subscription. It didn't need to be more complicated than that.
On the other hand, or hay, Firefox Screenshots!! Sooo useful. Pocket? It doesn't get more federated than that! Or the dozen of DOM APIs added every year, which are probably much more complicated to maintain than a simple RSS preview feature.
I really hate the general direction of how browsers are developed.
Enable forwarding to the new address. Update email contacts and accounts as needed.
Be sure to check that forwarding exists on your new provider, just in case you'll have to do the same when switching again.
Better yet: buy your own domain and use a service that allows you to use it.
Well, tear-free video on intel gfx would be a _big_ deal (you remember, stuff we had in the 80-90ies?).
Flicker-free boot is nice to have, but it's not a _big_ deal.
I can live just fine if the boot flickers twice. But somehow doing animation with tearing for the rest of the work-day is quite a bit more annoying.
I don't know the exact situation in Germany or US, but in Italy, the "no profit, no taxes" is definitely not true. Depending on the company type you registered, there's a significant cost to just keep the ability to run the company to _do_ business in the first place.
By experience, the dead cost of the smallest company you can run is between 5-15k per year. It might not seem much, but I've heard here on HN over and over how to grow a side/passive income, and there's basically no way to do this here. The moment you want to start a side business, the fixed minimal cost is sunk, so unless you start making a significant sum from the start you're just losing money that eats into your primary income. And there's no legal way to do the business below that. That's not how I understood people in the US do this sort of passive income. It sounds like "no money = no tax", but this is not true here. You often have to pay taxes in advance on the projected income of the next year, even if you never had a business first: the projection is based on god-knows-what market estimates you have no control over.
The market segmentation, language barrier and tax situation in EU is a huge burden. If you're working on a niche product you want to start with a wide basin of users, at least as large as the EU block. Sounds stupid to start in a single country. It's doable, but don't expect to start with a small capital, and typically not with the wannabe-VC we have here in the EU. The 100k for 3ppl/year is not a joke.. a "100k-300k" ballpark is very common for startups here. I'd consider that just for marketing, or even then. With this money you basically cannot do anything serious, just considering how hard is to penetrate the market.
I've yet to see something in the likes of Stripe in the EU. And a decent replacement for Paypal for smaller setups. I'd love to have candidates here. Accepting money is cumbersome if you're small. This is sad.
Workforce is a problem. But not because of talent. The extra regulation here implies a strong commitment when hiring. This forces companies to grow very cautiously. You cannot resize the workforce to match the load. If you grow too much, you may doom the company at the first financial difficulty. This causes a lot of sub-contractual work to be done, with a significant decrease in quality and cohesion. Not to mention, this line of working is being limited more and more over time - I was working as an entrepreneur in the beginning of my career but I cannot do that anymore and have to be regularly employed. I could have started something from scratch much more easily 15 years ago compared to now just due to regulations.
I could go on for pages...