SnowLprd

This smells heavily of astroturfing. Particularly because Headroom is a paid product, and that fact is not mentioned here or in the GitHub README.

Here was my experience…

I download and run the Mac application, which starts installing a bunch of things. Then the following happens without advance notice:

- Adds background item(s) from "Idiosyncratocracy BV"

- Downloads over 2 GB of files

- Pollutes home with ~/.headroom directory

- Adds hook(s) to ~/.claude/hooks/

- Modifies your ~/.claude/settings.json to add above hook(s)

… and then I see something in the settings that talks about creating an account. That's when I realized that this is a paid product, after all of the above has happened.

Headroom seems to use https://github.com/rtk-ai/rtk under the hood. What does Headroom offer over the actually-free RTK? Who knows.

At this point I have had it with this subterfuge — I immediately trash the app and every related file and folder I can find, of which there are many. Hopefully I got them all, but who knows. There should have been an easy way to uninstall this mess, but of course there isn't.

The lack of transparency here is really concerning.

What I said is an utterly factual statement: I found the experience to be user-hostile. You might have a different experience, and I will not deny you your experience even in the face of your clearly-stated intention to deny me mine.

Moreover, I already conveyed my understanding of and appreciation for the work open-source maintainers do, and I outright said above that I intend no disrespect.

On the subject of installing Ollama, I found it to be a frustrating and user-hostile experience. I instead recommend the much more user-friendly LLM[0] by Simon Willison.

Among the problems with Ollama include:

* Ollama silently adds a login item with no way to opt out: <https://github.com/jmorganca/ollama/issues/162>

* Ollama spawns at least four processes, some persistently in the background: 1 x Ollama application, 1 x `ollama` server component, 2 x Ollama Helper

* Ollama provides no information at install time about what directories will be created or where models will be downloaded.

* Ollama prompts users to install the `ollama` CLI tool, with admin access required, with no way to cancel, and with no way to even quit the application at that point. Ollama provides no clarity that about what is actually happening during this step: all it is doing is symlinking `/Applications/Ollama.app/Contents/Resources/ollama` to `/usr/local/bin/`

The worst part is that not only is none of this explained at install time, but the project README doesn’t tell you any of this information either. Potential users deserve to know what will happen on first launch, but when a PR arrived to at least provide that clarification in the README, Ollama maintainers summarily closed that PR and still have not rectified the aforementioned UX problems.

As an open source maintainer myself, I understand and appreciate that Ollama developers volunteer their time and energy into the project, and they can run it as they see fit. So I intend no disrespect. But these problems, and a seeming unwillingness to prioritize their resolution, caused me to delete Ollama from my system entirely.

As I said above, I think LLM[0] by Simon Willison is an excellent and user-friendly alternative.

[0] https://llm.datasette.io/

SEEKING FREELANCER | Remote

We seek experienced Django engineers to add new features to our product, which allows people to replace expensive SaaS tools with tap-to-install open-source applications. Lower costs, better privacy!

Tools/technologies:

* Django + PostgreSQL (required)

* HTMX and/or JS (preferred)

* Tailwind CSS (preferred)

We are looking for folks with about 20 hours/week of availability.

For more information, reach out to: entroP at gmail

SEEKING FREELANCER | Remote

We seek experienced Django engineers to add new features to our product, which allows people to replace expensive SaaS tools with tap-to-install open-source applications. Lower costs, better privacy!

Tools/technologies:

* Django + PostgreSQL (required)

* HTMX and/or JS (preferred)

* Tailwind CSS (preferred)

We are looking for folks with about 20 hours/week of availability.

For more information, reach out to: entroP at gmail

You have sunk to a new low, copy-pasting this same falsehood. The other comments here that speak of your past misdeeds are now all the more clear.

The comparisons to PyPy would be much more meaningful if they weren't based on a version of PyPy that's over two years old: PyPy 1.9 was released in 2012.

Not for me. Option-clicking produces no result for me on iTerm 1.0.0.20130319.

My tutorial for setting up fish on Mac OS X and Ubuntu: http://hackercodex.com/guide/install-fish-shell-mac-ubuntu/

I've never had any trouble using chsh to make fish the default shell. Bash scripts in crontabs still run under bash -- not sure why anyone would think otherwise. Plus, changing the shell command for iTerm/Terminal won't help with remote servers, so using chsh everywhere means you always get a consistent shell experience, no matter whether you're using your terminal locally or remotely.

I'd welcome any suggestions for improving the set-up guide, so fire away.

For those who want to give fish a spin, it might be worth checking out the guide I wrote on the topic:

http://hackercodex.com/guide/install-fish-shell-mac-ubuntu/

I'll soon have it updated for fish 2.1.0, Mavericks, and the new PPA locations.

Homebrewed Python includes the latest versions of pip and setuptools, making the command you suggested only necessary if you plan on sticking with the bundled system Python (which isn't recommended for reasons discussed in other comments here).

That's what the Back button is for.

Less-technical users don't need to know how to cmd/ctrl-click on links because even less-technical users know how to use the Back button. If they don't want to use the Back button and instead want to open links in new tabs, there are multiple mechanisms available to them (whether they know about them or not).

The reverse is not true: if you don't want to open a link in a new tab, but that behavior is being forced on you, there is no way to avoid it.

Regardless of the motive, this behavior is not a UX improvement.

Thanks for the detailed explanation. My unsolicited two cents is that forcing this behavior on site visitors isn't worth whatever value you get from the analytics data.

Perhaps I'm in the minority here, but I find this behavior to be offensive enough that I immediately stop reading and move on. Trading user experience for analytics data is not a good trade.

I'm aware that the malodorous motive you mentioned is often the reason behind this user-hostile behavior. I was hoping that wasn't the case here, and instead perhaps some cog in the publishing process was spuriously doing this automatically. Naïve of me, perhaps.

"Feel free to open an issue or submit pull request on Github."

Why does the link to the project on GitHub open in a new browser tab? Is there some reason this behavior is foisted on folks who would rather have the content open in the same tab? (Spoiler alert: I'm one of those folks.)

And, now that I take a closer look, it seems that every non-internal link on the page behaves the same way, spawning new tabs willy-nilly.

Looks like a useful project. I'm just legitimately curious why people do this.

We do our best to make Pelican as user-friendly as we can, but of course there are areas we'd like to improve upon. Community contributions to that end are most welcome. (^_^)

Another centralized service, sadly. I've decided that whenever possible, I will seek out decentralized solutions instead.

Looking for a decentralized, peer-to-peer file sharing and synchronization solution? I've been using BitTorrent Sync as a replacement for Dropbox, and so far I've been very pleased with it. Unlimited storage, no 3rd-party servers involved, and less CPU usage and UI lag than Dropbox. Did I mention that it's free? Check it out: http://labs.bittorrent.com/experiments/sync.html

Nice write-up, Honza. Thanks for the great post.

Here's the product page: http://www.bestbuy.com/pebble

This news makes me very disappointed in the company's handling of their KickStarter campaign.

I backed their KickStarter campaign and ordered a white Pebble in May of last year, and I still haven't received it. So if I understand correctly, someone who walks into Best Buy next week will get a Pebble before I do?

While I understand the desire to stay out in front of Apple, Sony, and any other companies who may enter the smartwatch market, as one of the people who funded and helped make the Pebble possible, I am disappointed at how this was handled. The whole experience will make me think twice about backing KS campaigns in the future.

If someone is able to accomplish what they want using the new build script functionality, why would they want to incur the learning curve, overhead, and complexity of Chef? Don't get me wrong — Chef is a powerful tool and has its place. But for many use cases, it's totally overkill. I think Docker's new build scripts may fit the bill nicely for a sizeable number of folks without needing to figure out how to integrate with an external configuration management system.

Edit: As shykes mentions, the two are really more complementary than overlapping. I'm planning to use Docker's new build scripts to construct pre-built Docker images, which I will subsequently deploy via Ansible (a configuration management tool akin to Chef). Up until today I was building Docker images via Ansible, but now I can handle that within Docker itself, freeing up Ansible to handle tasks better suited to its bailiwick.

Many thanks to shykes, mdaniel, backjlack, and the many others that contributed to this terrific release. So much has been accomplished in just a few months, which augurs well for what Docker will look like by year's end. Bravo, everyone.

That version is nearly a year old; the fishfish formula was temporary and will be removed from Homebrew as soon as the canonical fish formula has been updated to 2.0. Hopefully the Homebrew maintainers will merge this soon (not sure what the hold-up is): https://github.com/mxcl/homebrew/pull/19887

Same thing in fish. Either way works just fine.

I've been using fish with ssh-agent for the last year without any problems.

That's probably the old 1.23.1 version. Run "brew info fish" and that's most likely what you'll see. Homebrew maintainers, as noted above, have not yet merged the pull request: https://github.com/mxcl/homebrew/pull/19887

As nagisa said, you can simply use: . bin/activate.fish

Even better is Virtualfish, which I've been using and contributing to very happily: https://github.com/adambrenecki/virtualfish

🐟 Fish rocks. I've been using it exclusively for the last year, and I can't imagine giving it up.

There seem to be a number of misconceptions, which I will endeavor to address. The first is: "Fish isn't POSIX/bash-compliant, so there are compatibility problems." POSIX non-compliance is a feature, not a disadvantage, of the fish shell. It means there is less legacy baggage and syntactical inconsistency. I can count the number of POSIX/bash compliance-related issues I've had with fish on one hand, all of which were easily dealt with. For example, Vim assumes that your shell is sh compatible, but adding set shell=sh in your .vimrc solves that. The only other significant one for me was virtualenvwrapper, which doesn't support fish. Not a problem: Virtualfish solves that handily: https://github.com/adambrenecki/virtualfish

Want to run a bash script? Just run bash fooshnizzle.sh. Want to switch to bash for a moment? Run bash and then exit when you want to switch back to fish. This POSIX-compatibility topic is, in my opinion, much ado about nothing.

Another misunderstanding seems to be, "I can do XYZ in bash, but fish doesn't support that." Fish purposefully limits the number of "builtins" -- commands that fish includes by default -- in order to maintain simplicity. For me, that's a feature. When I find that there's something I want to be easier to do in fish, I whip up a tiny function to do it. Not only is that extremely easy to do in fish, but then that command performs precisely the way I want it to. I haven't pushed many of those to my dotfile repository yet, but you can check out some of my fish functions there: https://github.com/justinmayer/dotfiles/tree/master/fish

Fish is fast, the auto-completion is amazingly helpful, and it's intuitive to use without too much configuration. Give it a try. 🐟

I've been using and contributing to Virtualfish, which replicates nearly all of virtualenvwrapper's functionality. Highly recommended: https://github.com/adambrenecki/virtualfish

"Why are we doing this now? It's a statement of confidence."

Not desperation, but confidence. Riiiiiight.

Am I the only one who's not buying this?