loveknight

joined 3 weeks ago

Thanks, that's good to know, I'll see how well I can adapt my workflow to this. (The reason for using Konsole tabs so far is the easy switching via Alt+[number], but I suppose using Helix's integrated multi-document system should offer other advantages (e.g. regarding registers) that could outweigh this by far.)

 

When I'm editing with helix, I often have multiple instances of it running, one for each file, in different terminals (more precisely: in different tabs of my terminal emulator, Konsole). Currently, the title of these tabs reads just "Directoryname: helix". It would be really helpful if the titles included the current filename, so that I could see which tab has which file opened. Is there a way to do this?

[–] loveknight@programming.dev 1 points 3 days ago

Very specifically for learning about GNU/Linux and Unix, I highly recommend the book Classic Shell Scripting by Arnold Robbins and Nelson Beebe (O'Reilly Media, 2005).

ISBN: 9780596005955

I recently wrote the following about it in a post:

This book is extremely readable and gives a very good introduction to the various standard Unix shell commands (grep, sed, awk, tr, sort, to name but a few) and how to tie them together to do useful things. It’s very suitable if you have some experience with the command line at the level of individual commands but now want to see how to do construct more interesting pipelines and scripts. It includes an introduction to regular expressions. The fact that the book is already 20 years certainly means that some explanations and approaches are outdated, but since shell programming is at the core about text processing, almost all contents of the book are still highly relevant today.

23
submitted 3 days ago* (last edited 3 days ago) by loveknight@programming.dev to c/libre_hardware@lemmy.ml
 

I don't have to tell anyone that commercial printers suck (with the possible exception of Brother, but how long will this last?). I've read people on Lemmy talk about the viability of making a FOSS printer. I'd like to keep these thoughts going.

From what I remember, there are four main challenges, listed descendingly by their apparent difficulty:

  1. Handling ink
  2. Meeting legal regulations
  3. Moving the moving parts
  4. Patents

Patent difficulties indeed should be avoidable, since decent printers have been out there for way more than 20 years, the usual duration of a patent.

Moving the moving parts with the high precision necessary does at first glance seem daunting, but I've read people say that this is a problem many people know how to solve.

Meeting the legal obligations may ne trickier: Printer fingerprints? Aerosols? Other health and environmental hazards?

Handling ink: From what I remember, this would be the main difficulty (unfortunately I can't find that post or comment anymore). One should avoid the problem of creating an own cartridge & nozzle production by designing the printer such that it can use an existing cartridge model (one for which there are good third-party offers). Still, one would have to solve the apparently very difficult problem that the ink/toner has to be handled under very precise conditions, regarding things like flow velocity, drying rate, and perhaps temperature.

In view of these challenges, I've started to think that maybe the best approach would be to try our best to find ex-employees of printer companies and convince them that they would be doing humanity a huge service if they were to contribute with whatever they legally can towards developing a FOSS printer.

Also, I've wondered whether the time to do this may be running out: If even Brother one day starts to crack down on third-party ink/toner, all the producers for third-party ink/toner could eventually go out of business; so that one may successfully develop a FOSS printer, only to have no other ink in the stores than the price-gouged one, which was the reason to do all this in the first place.

Do you have any corrections, specifications, or further thoughts? I'd love to hear them.

 

ISBN: 9780596005955

This book is extremely readable and gives a very good introduction to the various standard Unix shell commands (grep, sed, awk, tr, sort to name but a few) and how to tie them together to do useful things. It's very suitable if you have some experience with the command line at the level of individual commands but now want to see how to do construct more interesting pipelines and scripts. It includes an introduction to regular expressions. The fact that the book is already 20 years certainly means that some explanations and approaches are outdated, but since shell programming is at the core about text processing, almost all contents of the book are still highly relevant today.

 

Things I would like every young web engineer to learn:

  • anything you can do in CSS + HTML, you should do in CSS + HTML
  • framework du jour is not a platform, it's a high-interest loan against your future capacity. The platform is the platform
  • understanding the memory hierarchy always matters
  • client-side isn't easier than the server, and "generalists" usually suck at client-side. Mind the (packet) gap
  • managers who are not technical are not useful
  • put users first, always

Second-order things to learn:

  • the way browsers work isn't static, but it also isn't changing that fast. Learn as much as you can and update every few years; particularly about networking and the rendering loop.
  • JS is the slowest way to do anything on the web. Never let it become the way you do everything.
  • a11y isn't nice-to-have, it's the job
  • shipping fast almost never matters as much as quality, & there are simple heuristics you can use to understand the difference
[–] loveknight@programming.dev 2 points 3 weeks ago

New to this instance, but for me too it is comparatively sluggish since I started using it yesterday.

[–] loveknight@programming.dev 15 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

Or get a used thin client (e. g. HP T620, T630, T640 or Dell Wyse 5070). Cost: ~40-100$. Biggest advantage: Passive cooling, i. e. they're absolutely quiet.