Hacker Newsnew | past | comments | ask | show | jobs | submit | blacklion's commentslogin

Somewhat tangent: x86-based laptops of this brand (it is new to me, I never meet Tuxedo Computers before) looks attractive, but there is no information about their screens main property: are they glossy or matt?

My wife is very sensitive to glossy screens and we have big problems to find new laptop for her, as most good ones are glossy now.


I use their InfinityBook Pro 14. Its 2880x1800 display is matte.


If she's ok with macOS, the new "nano-textured display" options on the MacBook Pros are very nice. I'm typing form one right now. It has the sharp color response of the glossy displays, but absolutely no noticeable glare.


One possible alternative is system76. Most of their laptop is matte https://system76.com/laptops/lemp13/configure


FYI you can add a matte layer yourself on any screen


Yes, you can even add a privacy protection layer that blocks viewing from larger angles.


This is infuriating. Everything should be matte unless you live in the dark.


KiCAD becomes better and better, but one limitation embedded into its DNA is very annoying: one project - one schematic - one PCB.

It is very kludgy and cumbersome to split project into several PCB (for example, stack of PCBs connected by backplane or headers, like Arduino & Shield for it) and/or to have variations of the PCBs for one schematics, like TH and SMD variants of the PCB for exactly same schematics.

Even in my very modest almost-electrical (as opposed to electronic) projects I need one or another from time to time.

As far as I understand it is limitation which is not easy to fix, because all architecture of KiCAD is based on this 1-1-1 principle.


My workaround for multiple PCB's for one schematic is to have the schematic as a top level sheet which can then be imported into sub-level projects. so each PCB becomes it's own project but use the common schematic sheet


Adobe products, for example. Or any of other of miriad of other products which have only Win/MacOS and no Linux support.

And, no, Wine cannot run anything.

You see, I don't need OS at all, I need applications. Some of these applications are "universal" (FireFox, for example), some has good equivalents, and some are unique to OS.

And, no, DarkTable, or RAW Therappe are not equivalent to Lightroom or Capture One. And no, there is no equivalent to foobar2000 among music players.


>And, no, Wine cannot run anything.

Wine may not be able to run the apps you need, but it can run plenty. The older the software gets the more wine becomes the only option to run it.


MPD + advanced clients pown foobar 2000 anytime. Also, Audacious, Strayberry...

Audacious with audacious-plugins could play anything (even video game music files) and it still has ProjectM plugins' support.


Nope, UI for mpd shows that there is 11093 albums in my collection, but first several screens of Albums is all sequences of `?`. Very useful. Number itself doesn't looks right, my estimation is at least half of this number, maybe less.

On the other hand same client shows only 6391 files, which is waaaay to small number if 1 file = 1 track. Ok, there is a lot of image + CUE albums, I wonder, is it 2 files or one?

So it is useless, unfortunately. foobar2000 allows me add folder / file set to playlist and start listening. With system "Artist/Year - Album" on the file system it is easy and convenient. Tags could be broken, but all mys music is here and I always know where to look for what I want to listen now.


When I've tried MPD last time (about 2 years ago, to be honest) it failed to play wv.iso format, and I have this abomination in my collection.

Also, it is not very good with broken tags, MP3 tags in local codepages (different for different albums!), etc.

You cannot imagine what can be seen in the wild when it is musical collection started in 1995!

Heck, I'm downloading mpd for windows right now and I'll try to add my collection into it. But I'm not holding my breath, all previous attempts to import my collection in any software failed for 15-20% of collection (different ones for different software).


You can run nearly any Windows app with winboat. Its not based on wine, it runs real windows in a container.


`LD_PRELOAD` works on UNIX-like systems too.


Thanks to LD_PRELOAD you could downgrade tons of OpenGL effects and enforce some settings for high end games and make them playable with good speeds on legacy systems.

Also to force texture sizes and whatnot.

I wish Wine/Proton had options for those, to override antialising, texture sizes, rendering resolution and everything.


that's an interesting pursuit. we've got the code, or at least we've got the stubs calling windows dlls.


Unfortunately, it doesn't help.

Almost any digital camera RAW format is TIFF inside. And you can see how much kludges good metadata library needs to read all of them: offsets from the IFD, offsets from beginning of file with or without header, offsets from fields in IFD, etc, etc, etc. You take TIFF, you change header to make your format, and then you cannot implement this TIFF properly!

Even DNG (which is tiff inside) is mangled by camera firmware authors!


I remember series of stick man fighting cartoons which starts from simple kung-fu/gun porno in big office tower of (presumably) evil corporation, but progressed to some infernal fights, with Jesus, ghosts, hell, etc.

I'm not sure it was XiaoXiao, I (don't) remember some other letter combination in the names of files.


Madness Combat


Yep, thank you!


I'm using FreeBSD for self-hosting, home NAS and router from version 2.2.0. As it is my hobby projects, I don't want to migrate to Linux which is, IMHO, over-represented.

But it become harder and harder in recent years.

Reason? Docker.

Many current «server-side» products doesn't have good instructions how to install them «by hands» and is not very suitable for system-side packaging (creating port), as they have build systems designed to be used in CI with online access in build time (especially node.js-based and go-based ones, but rust goes same way).

Installation instructions, well-defined dependencies, good versioning, immutable source distribution files? Nah. «Take this Docker file and run it».

It is pity.


This may help you.

« An introduction to OCI Containers on FreeBSD

October 31, 2025 »

https://freebsdfoundation.org/blog/oci-containers-on-freebsd...


Thank you, I've missed this one.

Problem is, these prepared images contain Linux binaries. Using Linux emulation in FreeBSD for OSS project doesn't feel ... right?


I am absolutely not pressuring anyone to do anything that doesn't feel right.

But FreeBSD can run Linux binaries without needing a VM or anything, using the built-in "linuxulator", and in recent releases this means it can directly execute Linux OCI containers.

Which is pretty close to running those same containers on top of a Linux kernel, when you're still bypassing much of the OS.


You can pretty much study the Dockerfile of each docker image and you'll see how it's installed. It's all there, no magic


Nokian studded tires for bicycles are (were?) the best! Rode many-many kilometers at winter with them!


What next? Replacing Sieve with something cumbersome, but JSON based?

There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help?

I don't think so.

What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

IMAP4 is underused by modern clients: it allows to effectively store client configuration on server, nobody implements it on client side. It allows to configure per-folder Sieve scripts, nobody implements it on client side. Nobody implements good Sieve client (with folder name autocomplition and such) even for global script, not to mention per-folder ones. Heck, there is no good Sieve editor! (I know about Sieve client built on Electron, it is not good, it is incomplete and buggy).

Servers are solved problem (sendmail, exim, postfix, dovecot, cyrus). Clients are not, they stagnated at the moment GMail was announced.


Solved problem? Dovecot can't handle UTF-8 to this day. Things like Stalwart do try and change that and actually support non-legacy features. (Though I think Stalwart doesn't do IMAP NOTIFY either.)

Clients on the other hand have actually kinda moved forward, Apple Mail works with IMAP servers and offers features that people only got with Gmail before. But there are many other examples as well.


What do you mean, dovecot can't handle UTF-8? It works with any properly MIME-encoded message on one hand and allows (even requires) proper UTF-8 for folder and namespace names on the other hand.

I don't have any problems to use UTF-8 in my messages received via dovecot and I have some folders with national characters on my account, and it works both with IMAP and Sieve.


No proper SMTPUTF8 support for starters.


dovecot is not SMTP server. And there is standard way to encode any charset in (almost any) message header for ages. We never will create e-mail messages with headers by hand in telnet session anymore, anyway.


> dovecot is not SMTP server.

Don't get confused by the name of the extension that it's somehow SMTP-only.

> And there is standard way to encode any charset in (almost any) message header for ages.

Actually, no. For example there is no allowed/standardised way to encode a MIME From address that uses UTF-8. It is only permitted to encode the non-structured part of a header such as the comment or phrase, but not the structured part (the address itself). It is also explicitly forbidden to encode anything in the Received header field.


My bad, I've dug dipper into the problem now and now see, that this is really a problem.

You are right.

But, again, what is simpler: add feature to existing OSS project or write all new protocols?

Second is more fun, for sure, I can understand that as programmer myself.


This extension amongst other features has not been implemented in Dovecot for a long time now. If it were easy (or easier) I'm sure it would be there already.

I do get the sentiment that building on top of old is usually better and more efficient, but this unfortunately does not carry over well to the entire ecosystem and each project. So it's better to replace in some cases, maybe not with a new protocol but a new implementation.

But to answer your question, you can actually do both. Stalwart both added the feature and support for all new protocols. It didn't take a decade either.


> What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

You need both. You could say, what profit is a good client without a server? By that reasoning, we never stake a step forward without a complete solution.

Now a better mail implementation is just a client away.


Problem with clients not protocols but UI&UX. New protocols can change nothing in this area.

Maybe, Apple Mail is good, again, I don't know as I'm not using Apple, but I don't know any client for Windows and/or OSS with Windows support which has as basic features as support of per-folder settings (identity, sorting mode, etc.) stored on server or proper support for Sieve. In my eyes it is basic features.

And don't let me start to rant about message editor itself, especially in text-only (as opposite to HTML) mode with proper quoting & such.


On a tangent: For do you use format-flowed in text-only that you send? I'm never quite sure if it's universally and effectively supported enough to implement for less-technical users, or better to just define the EOL (and lose dynamic adjustment to viewer width).


I had complains about "too long lines" in my e-mails many times and now try to use EOLs, unfortunately.

It is exactly what I said: all modern, GUI e-mail clients suck at basic functions, like displaying simple message with several layers of quotations and long lines, they cannot wrap lines with visually duplicating quotations properly, often they could not wrap even "new" (unquoted) lines at all and show horizontal scrollers. JMAP is no help here.

It was solved problem in age of terminal clients, heck, GoldEd for FIDOnet was able to do this in 1990s.

Instead of new protocols it was better to standardize MarkDown (+extension for nested quoting) in e-mails, but this train is long gone, I'm afraid.


I'm happy to have popups with "Reject All" button. If there is no "Reject All" button I close site immediately.

Cookie regulations are perfectly Ok, businesses which want to add 429 vendors and data processors to simple internet shop or corporate blog is not.

If you use cookies only for legitimate basic local functionality (like login and shopping cart on online shop site) you SHOULD NOT have any popups, there is exemption for such use cases in the regulations. Only if you want to sell data or pass it for processing to third party you need popup. Simply don't.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: