I can't recall the details, but this tool had quite some friction last time I tried downloading a site with it. Too many new definitions to learn too many knobs it asks you to tweak. I opted to use `wget` with the `--recursive` flag, which just did what I expected it to do out of the box: crawl all links you can find and download them. No tweaking needed, and nothing new to learn.
> Windows are a failed analogy as files-and-folders, normal people do not understand them and software for normal people rightfully don't use them
Weird claim regarding files and folders. In my experience, my pretty tech illiterate relatives have a pretty strong grasp for them. Younger people do not, because they only use mobile computers that don't make frequent use of that abstraction.
Why are they a failed analogy? What are normal people doing instead of using them?
UV creator's response on the concerns regarding VC money:
> I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).
> What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.
> An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]
> But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS.
I thought this problem will disappear upon switching to Kagi, but it suffers from the same disease, albeit to a lesser extent.
I remember reading a Google Search engineer on here explain that the engine just latches on some unrendered text in the HTML code. For example: hidden navbars, prefetch, sitemaps.
I was kinda shocked that Google themselves, having infinite resources, couldn't get the engine to realize which sections gets rendered... so that might have been a good excuse.
Judging by blog posts on HN, I got the impression that these vulnerabilities are often not rewarded at all, or rewarded by a minuscule amount. It almost seems like companies are begging hackers to sell these exploits. Perhaps because they aren't penalized by the regulator for breaches?
Re: securing SSH keys; Nowadays most password managers can store SSH keys and integrate nicely with your SSH agent, making it essentially equivalent to logging in with a password. I use KeepassXC[1], and the workflow consists of opening the database using my master password, then just `ssh machine`, so in my book it's at the same level of comfort as a web interface for your cloud provider
Am I missing something? There seems to be very little substance here: No link to the presentation itself, only slides that lay a very ordinary introduction. Mentioning GitHub stars may have been the first red flag
This sounds exactly like what I was looking for. I settled on htbuilder[1], but it certainly does not feel right as it requires a fair bit of wrangling in order to fit with Django.
I'd love to help you with documentation and such; hit me up at [email protected] if you'd like a partner(:
EDIT: Actually, scrolling further in this thread, it looks like https://htpy.dev fits the bill? It has explicit integration with Django, which is what I was looking for.
I found the text a bit too reference-y, as in giving too much theoretical background, while what I'm actually looking for is workflow breakdown. The demo video at the top of the page[1] demonstrates it beautifully and I recommend you go give it a watch.
It's up to app developers, and some of them indeed just straight up lie with their categorization. Moovit and all dating apps come to mind. They implemented _some_ categories, but none useful – nothing that lets you separate wheat from the chaff
Why did you choose to roll your own modules rather than do what's described in the comment you replied to, i.e. provide a Python layer for interacting with the rich set of available Ansible modules?
Not trying to be rude ofc, I'm sure you considered it and have a good reason – just curious as of what it is. An incredible project you put there, nonetheless:)
In my case, I already write a considerable amount of presentation logic in my the Django side of my project, merely because of Django's templating language limitations (which is okay, I prefer writing it in a sane language instead of wrangling esoteric features of DTL to get what I want). So adding a view function for an HTMX endpoint isn't really "spreading it around the backend" if your workflow is similar to what I described.
You might enjoy this TikTok video of an ex-CloudFlare employee getting laid off by people she has never met, and responds as fiercely as your text. Except she's also trying to extract the actual reason she's being laid off, to no avail – yet still impressive how hard she's pressing those random HRs.
If I correctly understand your point, then it's worth noting the article is using a container merely to showcase the different parts of systemd in a sterile, reproducible environment. They're not running containers as systemd services, even though that's possible with podman