wakeupcall

In one of my work experiences, "titles" were used as opposed to (or with a meager) paycheck raises. The most ridiculous aspect was that we had a fair number of group leaders, each with a team of 1 (just themselves).

For some it was effective.

This isn't reflecting the OP case though.

When "quickly" means downloading 242mb of runtime, running it slower than native, on top of the document you want to preview...

It was based on Slic3r, however I urge you to diff the sources to see how much has been rewritten and extended. Plain Slic3r is too far behind both PrusaSlicer and Cura nowdays.

Back before 2004, QNX could have still been relevant as there was still a lot of OS experimentation from the user/developer themsevels. They could have attracted enough people to carve a niche even in the desktop space at that time.

After beos failed, I played/developed with QNX until they pulled the rug. I was on it full time on my main dev machine. I loved it.

When they closed it I got severely burned to the point that I will not touch a any closed development platform. I see from the license they didn't change a bit.

Not that it matters anymore.. they're largely irrelevant today except for whatever existing markets they already have. It would be fooling to choose QNX today: we now have good alternatives, and all of them with open licenses.

Some months ago I wanted to format/print some documents, and given the existing tooling I had I decided to try the html->pdf route. I fully agree is a shitshow. The way things break across pages is hard to fix even when hand-tuning the html itself (not just by working it around with css) to avoid content being cut across margins and pages no matter what. I've found chrome to be "less bad", but still unusable. Column handling is even a bigger joke.

In the end I exported the document to libreoffice, and got something way more usable in a few hours just by editing the styles than whatever I was able to do in days of fiddling with html+browser.

iBooks on apple might get a pass as it doesn't need to paginate, but truth be told it seems that epub/ebooks and ereaders in general are being targeted at novels and romance, where form factor, typesetting and formatting doesn't matter that much.

I have access to ebooks through my local library and there's no way I would use, let alone buy, any technical ebook.

Not to mention, I've seen a steady average decline in the quality of printed media in general over the last ~15 years. A lot less attention is put in the typesetting and layout. Even the print quality itself is lower, which I think is due to the smaller and cheaper print runs being done now also for more popular titles.

The more likely reality is that we have a lot of v4-only hw in place with lifespan of 20+ years. Those devices won't go away.

Heck, I work on embedded, and having a dual-stack system is just a PITA to deal with. If v6 would have been fully retro-compatible this wouldn't have been something to think about, but you can't drop v4 and there's no future in sight where v6 will be the only choice (we'll have dual-stack for a looooong time), so we just push the problem up the chain.

There are plenty of systems being developed _now_ which are still v4 only as a result.

If that matches my experience, outdoors helps a bit, but not much. Overall you get better contrast and brightness, but the fact that the background is "gray" and not white becomes even more obvious.

That being said the rm3 is usable without backlight indoors if the place is decently lit (for example, in most offices), but requires some backlight otherwise. The rm2 is usable also in poorly lit conditions.

Anyone with some critical experience also with the ipad pro pen?

I'd really like some comments there. There's a lot that goes into writing and drawing, and all the online reviews I've seen seem just to praise it.

I used most digital writing devices starting from wacom tables (first intuos series), to laptops with foldable screens and currently using the rm2/rm3.

I agree that nothing still has the precision of a real pen or pencil. I can lazily fill and shade even with a micron fineliner when I want, and simply can't replicate the same precision with anything else I tried. I could buy a lifetime supply of the best pens and paper with the cost of the rm3.

Writing is mostly fine, but when drawing I notice immediately the precision just isn't there. But still, at least on the rm (both 2 and pro), the digitizer is well calibrated, and the feel is good, the pen is actually like a pen and not the sucky abomination what wacom like to call "pens" or the tiny unusable styluses of the samsung "note" or lenovo yoga series. The show distance between tip and display is very good, and even though it seems ridicolous, the slighltly shorter one on the rm3 makes a difference. The rm2 is still requires a bit too much pressure for my taste (I have a light touch being used to mechanical pencils, fineliners and tech drawing); the rm3 seems slightly improved.

I can still tell instantly that lines are occasionally wobbly due to the digitizer's grid and pen position.

That being said I got the rm2 at some point, and it's the first e-notebook I actually stuck with because it's effectively "endless paper" and has reached the "good enough" feeling for me. I used to have tons of sheets of paper with notes, now I have somewhat less ;).

I'm a happy owner of the latest rm pro, but I was curious about the boox. You're actually saying the boox is even more muted and darker?

In the rm pro the colors are still what I consider to be pretty muted. I had a laugh of what "red" looks like then I tried it. I don't care too much about it, for the purpose it's a great addition, but it's also darker than the rm2, which instead turned out to bother me a lot.

I can use the rm2 everywhere, but the rm3 is only saved, in my eyes, by some amount of backlight, which brings it closer, but still not exacly equal to the rm2. And by the way the rm2 is also, by far, not "white". If I consider rm2 to be some shade of ivory, the rm3 is downright gray.

Grayscale rendering on the rm2 display is also better. I do notice the dithering on the rm pro, and there's some color fringing in the ghosting.

Also running FF with strict privacy settings and several blockers. The annoyances are constantly increasing. Cloudflare, captchas, "we think you're a bot", constantly recurring cookie popups and absurd requirements are making me hate most of the websites and services I hit nowdays.

I tried for a long time to get around it, but now when I hit a website like this just close the tab and don't bother anymore.

What about fully client-rendered templates/sites that require JS for visualization? (ie, no graceful degradation at all).

Technically static, but absolutely of the worst kind in my opinion.

Great analysis, but I'm even more surprised to discover that producthunt is a "real" website at all.

I blocked PH with ublacklist a long time ago for looking like SEO promotion/garbage and looking too much like those "VS/comparison/best 5 apps" websites with next to zero content. These pop out faster than what I can filter by hand.

After checking it out again and knowing it is not purely-generated content, I _STILL_ don't see the value proposition if I stumbled on such a result.

will often change so quickly that your search term is nowhere to be found

About 5 years ago I was often pulling up the cache to see if the indexed/cached page actually contained the search terms I was looking up, suspecting the site was serving a different page compared to what I was redirected to.

The number of websites doing this to game SEO was (and I suspect still is) substantial, despite google saying they're penalizing this behavior.

Outlets serving full articles to google then presenting you an unreadable mess, often downgraded through JS, is one of the most egregious, and google doesn't seem to care anyway.

This was before I gave up completely on google giving me pages containing the terms I was looking for.

It's a work-around at best, and not a nice one if you consider the wasted disk space.

I don't understand why all vendors are actively trying to kill S3 sleep. It doesn't make any sense.

Onshape is great. I use it as well for random things.

I do expect them to do a pull-rug on the free license at some point, like fusion did, especially now that they've been bought by PTC. If they do, the commercial license is too expensive IMHO compared to other offerings for what they offer.

I had the option to use the educational license at some point, but we couldn't get to renew it (ironically, we got a dirt-cheap Creo license afterwards).

Just to keep things in mind it can go anyday from free to too-expensive.

I had a few complex designs in fusion360 I essentially lost at some points due to the price hikes. I decided to endure the pain in freecad. It's getting better.

BricsCAD is ok. It's more of a direct modeler with constraint support though. It may or may not matter to you depending on the kind of work.

I tried it for a while, and while I generally liked it, also got stumped by the artificial limitation of STEP import/export, which made it a non-starter even for hobby projects. This is, IMHO, the dumbest thing they could do in terms of licensing.

I still recommend RealThunder's fork (https://github.com/realthunder/FreeCAD/) at the moment, even though his fork is a bit lagging at the moment.

Most of his contributions to the topology fixes got merged back into freecad now, but his enhancements to UI/behavior aren't (yet), and they make a night and day compared to ondsel too.

I didn't find any significant limitation to RealThunder's assembly3.

In any case, while far from most commercial offerings, FreeCAD is progressing and the future looks bright. I've stopped using f360/onshape in the last years for my hobby designs. Once you know the specific limitations of freecad+occt (something you learn in each cad program) and how to work them around effectively, it's already pretty powerful.

This is not anti-learning. This would be akin to git changing command names and flags doing exactly the same stuff. After a couple of times happening, even if the changes are somewhat ok, you too would start to be frustrated.

I've seen healthcare management software evolution due to my partner working with it. As in the worst management story, it's pitched to a boss that doesn't need or want to use it, offered to generally the lowest bidder, and then immediately outsourced in parts that rarely work well together taking years to develop.

The UI and workflows are designed by people that will never use it and are just plainly bad. The software/UI takes years to stabilize and reach feature parity to the same level it was before. During that time, it's pretty common to see staff having to use both systems and perform double data entry.

You're not learning to improve anything here. You're substituting a [shitty] tool with another one which does _exactly_ the same.

Sadly in IT this is pretty common. There's nothing special about healthcare.

The way I see it is "I'll have fun at something that feels interesting"

As pointed out, these do exist. I've been using several over the decades. And chrome forks too.

They all tend to lag behind over time, until the fork is eventually too old and it's either abandoned, useful changes I was relying on are dropped, or becomes just too old compared to upstream to be fully compatible (and thus just annoying to use).

Just the burden to upkeep the upstream changes, in either firefox or chrome forks, seems to be significant enough that I'm quite pessimistic on the lifespan of these projects.

You might just as well do your own thing, and don't pretend to be a mainstream browser replacement altogether.

I also find that line hilarious, but maybe it's intended as in "size adjustable down to the millimeter".

CAD programs are generally unitless. You can design a box with OpenSCAD "down to a micrometer" if you want.

Designing a joint that works well also will poorly 3d-printed parts is usually what matters, but it's not like we're lacking customizable solutions:

https://www.printables.com/model/757297

(not detracting from the website.. just commenting on the headline)

Depending on context, I cycle between espeak-ng with mbrola-en or RHVoice, but even plain espeak shouldn't be discarded.

RHVoice sounds slightly more natural in some cases, but one advantage of espeak-ng is that the text parsing logic is cleaner, by default.

For example, RHVoice likes to spell a lot regular text formatting. One example would be spelling " -- " as dash-dash instead of pausing between sentences. So while text sounds a little more natural, it's actually harder to understand in context unless the text is clean to begin with.

I don't know if speech-dispatcher does this for you, but I'm using a shell script and some regex rules to make the text cleaner for TTS which I don't need when using espeak-ng.

Another tradeoff: espeak-ng with the mbrola doesn't offer all the inflexion customization options you have with the "robotic-sounding" voices. When accelerating speech, these options make a qualitative difference in my experience.

I can see why each of these can have its place.

Indeed. Not to mention, aside from a few "jumps", most of the falls in the video seem unwanted/slips due to pushing. Uncoordinated, and hitting the water pretty much randomly.

It definitely was for me too, and because it had _everything_, thanks to piracy. I started listening mostly mainstream bands, because that's what I knew, and within a few months I was listening to absolutely random authors, genres and "things" I didn't know existed. And by that I mean stuff like old sega genesis video game music somebody uploaded - without even knowing what the genesis was.

I never BOUGHT so much music since. It was eye opening for me how little I cared about radio/mainstream music after that.

The closest I've found so far is soundcloud. Thanks in no small part due to the barely-working recommendation engine, which doesn't get stuck in a local maxima, frequently going offtrack in pleasant unexpected ways.

I didn't think of "identity" in this sense, but I don't see this as a show-stopper either.

On my current jig developer churn is not high, yet I've only recently met developers hired 6+ months ago. I know first-hand only a handful of the committers I see. Barely know the most common commiters. I generally do watch commits of the trees/projects I'm interested into, but I'm a minority, and such behavior wouldn't catch something similar to the xz situation unless I'm absolutely lucky.

This also ignores the fact that you can just as well corrupt a current employee.

but there's also much more upfront validation on who gets to change it.

Very doubtful in my eyes. Very few companies have the strict validation which would be required to catch this.

Good validation that goes into central components is often skimped on arbitrary deadlines, which companies are full of. On something tangential like this I suspect nobody would really notice.

I can also hear the "I noticed now there's an extra delay which isn't supposed to be there, can I investigate?" "Sorry, but this is not critical for this deadline" agile mentality.

A bit late to respond, but this is not an user error. From the bug description it SEEMS (because there's still zero feedback from the dev's front) that it's Element itself failing to send the keys in the first place, probably due to a mishandled connection/transmit error and not attempting to retry. It's not a protocol error, unless you count the fact there isn't a mechanism in place to ack at least asynchronously that decryption is ok.

This is compounded by the fact that there seems no mechanism to recover for the receiver. The receiving client is just oblivious, it will _never_ be able to decrypt the messages and thus also never be able to backup the session keys if none of the clients associated with the account ever received the keys.

The suggested work-around is forcing the sending client to rotate the session keys earlier and thus fix the _following_ messages only.

I've been in situations where two element clients (both sending and receiving) failed to decrypt each other's messages.

This is a pretty damning issue for a client that enables encryption by default.

We also tried to use it, but frequently, messages will fail to decrypt with no option to retry.

This is a years-old issue with Element, which never happened to me with other sending clients such as FluffyChat. It's unbelievable that it's unfixed given it's a dealbreaker as it results in permanently unreadable messages on your end (the "waiting" in "waiting for this message" is a lie). And since this needs to be fixed on the sending side, you NEED to use another messenger to fix the conversation (if at all, as this requires reading extremely long issues on github with buried suggestions many won't do).

After getting it a few times most users would just dump Element and blame matrix as a failure to never touch it again. The excuse "we're working on this on the next client iteration" is actually ensuring a growing list of users will hit this (as it's bound to happen) and avoid matrix in the future.

UI/onboarding issues are minor compared to the fact that the conversation can be randomly broken.

It's not a great request/tone, and neither is the answer...

Update checks and auto-updates for OSS are often an anti-feature though, not for the "surveillance" argument which is silly, but because update checks are often performed by distributions using the package, and it's often double work on the distributor part to change the default, something it's easily missed while packaging.

Expecting that your software does unexpected network requests where it shouldn't is also something I agree with, even if those are benign. Many people seem to think that software is going overboard with this, as stuff like little-snitch wouldn't be popular otherwise and thrust has been _already_ been eroded completely on commercial software.

zsh's has "cdr" as part of the standard distribution, which I have been using for years. See zshcontrib.

I wonder if anyone can make a comparison. From an usage perspective, they seem equivalent. cdr's configuration is more zsh-like.