hambes

then why did my keyword-based approach work better than the natural language approach?

OP specifically said they were looking for luks commands.

even ddg has integrated AI now and while it can be disabled, the privacy aspect seems to mean that ddg regularily forgets my settings and re-enables the ai features.

maybe i'm doing something wrong here, but even ddg is annoying me with this.

Is "How do you set up an encrypted file on linux that can be mounted and accessed same as a hard drive." literally what you put into the search bar? if so, that's the problem.

try "mount luks encrypted file" or "luks file mount". too many words and any grammar at all will degrade your results. it's all about keywords

edit: after trying it myself i quickly realized the problem - luks related articles are usually about drives or partitions, not about files. this search got me what i wanted: "luks mount file -partition -filesystem" i found this article[1], which is in german (my native tongue), but contained the right information.

1: https://blog.netways.de/blog/2018/07/25/verschluesselten-fil...

I've thought about getting a web browser to work on the terminal for a while now. This is an idea that hadn't occured to me yet and I'm intrigued.

But I feel it doesn't solve the main issue of terminal-based web browsing. Displaying HTML in the terminal is often kind of ugly and css-based fanciness does not work at all, but that can usually just be ignored. The main problem is javascript and dynamic content, which this approach just ignores.

So no real step forward for cli web browsing, imo.

honest question, since i really like the idea but don't understand the implementation:

what use is a text-based desktop environment, if it requires a graphical interface and cannot run in a tty?

All three of your examples deserve to be thoroughly criticized for their waste of energy and resources. What even is this argument?

As other's have said, arguing with disputable estimate isn't great. It's even worse if you don't understand physical units and miscalculate. Assuming the assumed 2Wh per prompt are correct, the calculation "2Wh * 20mio users * 24h" for a daily consumption makes no sense, since multiplying Watt-hours with time does not work. If we assume that each user generates one prompt per day, the actual (still very disputable) calculation would be 2Wh * 20mio users = 40mio Wh usage per day, which would be - according to the author's comparison - around 1000 households per day. Which isn't a lot.

I believe that energy consumption with AI is a large problem, but articles like this unfortunately do not provide a basis for arguments.

I think the graphic used by divio[1] ist so much more intuitive. But seems Diátaxis has more comprehensive documentation on what they mean.

1: https://docs.divio.com/documentation-system/

Yeah, sounds honestly very obvious. Writing by hand is much more complicated than writing with a typewriter. However, nothing about the brain activity suggests that the increased learning effect has anything to do with the content of what is written. I propose that the increased brain activity is exclusively because one learns _to write_, but not what is written.

I've been using Tabby Cat [1] for a few years now and under no circumstance will I replace my cute cats with a productivity tool.

[1] https://chromewebstore.google.com/detail/tabby-cat/mefhakmgc...

I don't understand your point. The lesson is "don't rely on magic strings, instead rely on exported and documented constants, otherwise your code might break".

It might look worse than catch, but it's much more predictable and less goto-y.

Unfortunately true. The Go maintainers might not agree with me on this, but I think in this case consumers have to learn the hard way. Go tries to always be backwards compatible, but I don't think that trying to be backwards compatible with incorrect usage is ever the right choice.

Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1].

More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value againnst the constant instead of hard-coding the contained string themselves.

Hyrum's Law is definitely a thing, but its effects can be mitigated.

[1]: https://thomas-guettler.de/go/wrapping-and-sentinel-errors

I'm quite weirded out about the part about sharing google's data with other companies to allow competition. Yes, sharing my data allows other companies to advertise to me and to monetize my interests. No, I don't want that. I don't even want google to do that.

I really hate the phrase "from scratch" in the title.

It depends on whether you often need to reach across the keyboard middle. If you need to press keys on the left half with your right hand or the other way around, it will be uncomfortable.

Specifically for shooters I've found it pretty great though. I usually only need the left half of the keyboard anyway, since the right hand almost exclusively uses the mouse. Having a split keyboard means I can push the right half back and have more space for the mouse.

I am, however, also the kind of person that rebinds 80% of hotkeys in games to what I like, so I will always go to the trouble of binding every single important action to a key on the left half of the keyboard in shooters. So take that with a grain of salt.

> We want curious conversation here

And the multiple hundreds of "oh so sad rip i'm not a royalist but..." posts above are _curious_ and don't need discouraging?

Put in work once, get paid over a long span of time in a way that is not proportional to the effort you put in at the start. Like any other passive income.

Please, please, please do not throw anything that is not derived from Error. Throwing literals or other things makes error handling so much less predictable, stable and useful. throw/catch is already bad, let's not make it worse than it needs to be.

Given how obviously stupid many of the changes are, to me this looks like a false flag attempt trying to stir outrage against a movement with good intentions.

> finding that both male and female participants tend to assign positive traits to women

Pretty simple to summarize imo

You do understand the word "benevolent", don't you? Have you read the linked article on "ambivalent sexism"?

The difference is between using a keyboard shortcut like vim's "yaw" to copy a word vs vim's "d3f," to delete the next three words. The former you can save to muscle memory and always do instantly. The latter you have to think about, because you need to adjust it to your needs in the moment. That will always take a moment of thinking time.

Makes me think they have not met a single addict ever. This quote makes absolutely zero sense. Most addicts stay addicts for the rest of their lives. They fight their addiction most days if not every day.