Ok but when I run it on my notebook, WiFi is slow, the laptop crashes when I connect it to a docking station, audio doesn't work and suspend and resume is broken. And this on a Linux certified machine.
'notebook computer' is so ambiguous as to be useless.
go find one of those 'notebook computer's that the dev team uses (probably a few-generations-old thinkpad or dell) and go see what the experience is like if you're unwilling or unable to put the work into getting your machine to run as you wish.
furthermore this isn't a solved issue for ANY OS on the fringe of the computer market. Go install the newest version of Windows on a Chuwi machine and see how many drivers are MIA and functionalities lost. Install Linux on an obscure VAIO or Toughbook and see what happens.
Regardless of the promises and hoped-for-wishes, EVERY os is hardware-centric, and they all have different orbits.
The BSDs just tend to make choices that give them one of the widest arrangement of choices in the 'will-it-run-on-this' category.
> EVERY os is hardware-centric, and they all have different orbits
Kind of why I like macOS (works fine on any Mac, with about 7 years of support – though I wish it were 10, and x86 support may stop sooner) and Windows (runs on any x86 PC, games work without issue, years of updates and backward compatibility.)
But on a mainstream x86 laptop like a ThinkPad, I'd expect Ubuntu/Debian/etc. and FreeBSD to work well, for 10 years or more of updates. (And I'd expect most games to work on Linux with Proton.)
In my limited experience with NetBSD, it ran extremely slow on my Raspberry PI. Google took me to a forum in which the last response was "you have a bad SD Card, get a better one".
Strange, because when I wipe the card and put FreeBSD or Linux on it, it runs fine.
Depends on which point of your career. With 18 years of experience, consulting for tech companies, I can afford to be tired of AI. I don't get paid to write boilerplate code, and avoiding anyone knocking at the door with yet another great AI-powered idea makes commercial sense, just like I have ignored everyone wanting to build the next blockchain product 5 years ago, with no major loss of income.
Also, running a bootstrapped business, I have bigger fishes to fry than playing mentor to Copilot to write a React component or generating bullshit copy for my website.
I'm not sure we need more FUD saying that the choice is between AI or unemployment.
I find comparisons between AI and blockchain very misleading.
Blockchain is almost entirely useless in practice. I have no reason to disdain it, in fact I was active in crypto around 10-12 years ago when I was younger and more excited about tech than now, and I had fun. But the fact is that the utility that it has brought to most of society is essentially to have some more speculative assets to gamble on, at ludicrous energy and emissions costs.
Generative AI, on the other hand, is something I'm already using almost every day and it's saving me work. There may be a bubble but it will be more like the dotcom bubble (i.e., not because the tech is useless, but because many companies jump to make quick bucks without even knowing much about the tech).
I mean, to be selfish at apparently a dicey point in history, go ahead and FUD and get people to believe this.
None of my useful work is AI-able, and some of the useful work is towards being able to stand apart from what is obviously generated drivel. Sounds like the previous poster with the bootstrapped business is in a similar position.
Apparently AI is destroying my potential competition. That seems unfair, but I didn't tell 'em to make such an awful mistake. How loudly am I obliged to go 'stop, don't, come back'?
When it's for sale everywhere (I cannot buy one) and people trust it, all cab drivers will be gone. Unemployed will depend on the resilience, but unlike cars replacing coach drivers, there is not really a similar thing a cab driver can pivot to.
Yes, we can imagine a future where all cab drivers are unemployed, replaced by autonomous driving. However, we don't know when this will happen, because autonomous driving is a much harder problem than the hype from a few years ago suggested. There isn't even proof that autonomous driving will ever be able to fully replace human drivers.
You’re feeling tired of AI, but let’s delve deeper into that sentiment for a moment. AI isn’t just a passing trend—it’s a multifaceted tool that continues to elevate the way we engage with technology, knowledge, and even each other. By harnessing the capabilities of artificial intelligence, we allow ourselves to explore new frontiers of creativity, problem-solving, and efficiency.
The interplay between human intuition and AI’s data-driven insights creates a dynamic that enriches both. Rather than feeling overwhelmed by it, imagine the opportunities—how AI can shoulder the burdens of mundane tasks, freeing you to focus on the more nuanced, human elements of life.
The author of the install instruction, because "sudo chown -R $(whoami) /usr/local" first gained popularity in how to install Homebrew in macOS.
Homebrew assumed it was being installed on a single-user-at-a-time system, and it didn't want the risk of a bug in its ruby scripting being exploited somehow by insisting on running as root, and it chose /usr/local to install to as it was already in the path... all of these are anathema to Linux users.
* A package manager should leave /usr/local alone as its purpose is to host the user's own software, not distributed software (that's /usr) or vendor software (that's /opt)
* A package manager should run as root, or run its install-the-files portion as root, because it should require the user's admin authority _at that time_ to be permitted to install software that will be in the path of _other users of the system_. If the user takes ownership of the system directory instead, then all their other processes can mess with it too, not just the package manager.
The right thing to do is to install to e.g. /opt/homebrew, and then require users to add /opt/homebrew/bin to their own PATH, which is what Homebrew now does. It only did it after Apple fought against them by using System Integrity Protection to prevent users changing the ownership of /usr/local -- for a while Homebrew told users to write "sudo chown ... /usr/local/*" rather than "sudo chown ... /usr/local" to get around that, and that's what we see here.
The right place for this software on Linux is under /opt or /srv, and it should have the equivalent of "sudo make install", where root is required to install the software to the right place (and after installed there, it can't be modified by regular users), and root is _only_ required for that install step, nothing else.
EDIT: I'm unable to reply to the person whose question I answered, but I'd commend the GP for spotting the macOSism, and recommend everybody be alert to these sorts of tells and impedence-mismatches. You can often spot experienced Windows users doing "Windowsisms" in Linux... and vice-versa! You can see people writing Rubyisms in Python, Cisms in Java, and so on. There's a risk that if they don't adopt the appropriate native idioms for the language/environment/OS, they will introduce subtle bugs, sometimes security bugs. Be on the lookout for this.
> first gained popularity in how to install Homebrew in macOS
That doesn't really make the argument that it's a macOS user who wrote it though does it? It just makes the argument that it was potentially inspired by Homebrew, which has existed on Linux for half a decade.
I didn't really read the rest of your spiel in detail. I asked why you have an opinion about a person I didn't ask for a breakdown of package management and software installation best practices for the last few decades.
Org mode seems to be missing right now. It looks like its aimed more at only programming right now but I can totally see it getting a proper orgmode in the future. It's far more hackable than emacs is!
httpd with some critical files; I'm taking a diversified approach of offline storage and various OS hosts to store the keychains and other things I'd need to bootstrap connectivity to the remaining online services, and maybe I'll host some personal pages as well.
I got annoyed with the openssh bugs this summer and figured I should have some hosts I can mostly not worry about.
In general, I think I want OpenBSD to be the Internet-facing hosts as much as possible, so looking into proxy options for TLS+QUIC.
Sorry, but I hate server-side "helper" functions that generate HTML. For one thing it's never the same as what eventually gets shown on the page. 99.9% of the time you're missing attributes when needs to be hacked around. Debugging is a nightmare. Refactoring is hell. And css programmers have no clue what to do with this.
Maybe I'm missing something here. Why not a templating engine?
In this case, it's a 1:1 mapping to what's on the page, so your concern doesn't apply here. Debugging and refactoring is far easier with Python functions than templates, and CSS programmers just use CSS the usual way.
Templates were originally created for web development in the 1990s, back when web design required complex browser-specific HTML. By using templates, designers were able to work in a familiar language, and programmers could “fill in the blanks” with the data they needed. Today this is not needed, since we can create simple semantic HTML, and use CSS to style it.
Templates have a number of disadvantages, for instance:
- They require a separate language to write the templates, which is an additional learning curve
- Template languages are generally less concise and powerful than Python
- Refactoring a template into sub-components is harder than refactoring Python code
- Templates generally require separate files
- Templates generally do not support the Python debugger.
By using Python as the HTML-generation language, we can avoid these disadvantages. More importantly, we can create a rich ecosystem of tools and frameworks available as pip-installable Python modules, which can be used to build web applications.
> - They require a separate language to write the templates, which is an additional learning curve
Sure, but that's an advantage, not the learning curve obviously. You can't use FastHTML without knowing HTML anyway, at least not from the examples. In fact it's a really complicated way to do HTML. Jinja2 or Django templates are closer to HTML and much easier to reason about.
> - Templates generally require separate files
Again, that's an advantage. Someone who are not familiar with Python could easily update the HTML, and someone who knows Python most likely also know at least some basic HTML.
I don't like this, at all, but I'm also not required to use it.
What do you have trouble reasoning about regarding FastHTML python compared to Jinja2 or Django templates?
To me, it seems like a direct translation, and that's what makes it easy to reason about. I'm curious about what situations you find more intuitive to use Jinja2 over Python.
For example, in FastHTML:
P() -> <p></p>
Div(P()) -> <div><p></p></div>
The lack of a big transformation layer and things being 1:1 is what makes me think it's just as easy to reason about, but it comes with the advantage of a more powerful Python over a templating language.
I agree that this wouldn't be a great solution if you want people who don't know Python to make HTML edits.
> You can't use FastHTML without knowing HTML anyway
We are not talking about the learning curve for HTML but of Django or Jinja or Mustache or whatever templating engines and their special syntax for loops, conditionals, etc.
I think you are missing how htmx (https://htmx.org/) is intended to be used. You still have your regular HTML page and by interacting with that HTML, you trigger server-side functions that return HTML. That HTML is used to update only a small part of your page. htmx works with HTML fragments while HTML templates work with entire pages.
They are awkward to use, usually have a foreign syntax of its own and scale poor with dynamic languages (in terms of ability, not speed). But I also think this solution here is not that good either. It's ok for small stuff or purely tag-based output, but if you have many parameters, it becomes ugly really fast.
We've used those HTML-generators 20 years ago, and they were not really popular. I still use this still for bland XML today. But I can't see this scaling well for a complex website. Maybe there are some more features I've not seen in the documentation, but otherwise I think they should step up some more gears for this. But on the other side, I guess you are not forced to use the helper-functions. At the end they are probably just strings shoved around, so you can use whatever template-engine or string-generator you prefer.
reply