emacsen

Most of the time knives that are too sharp are much more dangerous than knives that are too blunt.

With a sharp knife, you cut through food very easily so you use very little force. You also use techniques that prevent you from getting hurt, such as the claw ( https://www.thekitchn.com/knife-skills-the-claw-75998 ).

But if someone has used a dull knife for most of their life, they may not have cultivated these skills and may hold their knife in an unsafe way and or use a lot of force when cutting.

For someone like that, a sharp knife could be a lot more dangerous, but if they're trained/using it properly, a sharp knife is a lot more safe as it reduces effort and chance of the knife slipping.

I'm a bit confused at the ways HTMX and Alpine AJAX differ and where they're the same. I know there are header difference, for example, and that HTMX may have some functionality Alpine is missing, etc.

For example, HTMX has websocket support, while it looks like Alpine doesn't. Alpine has Alpine AJAX, but also alpine-morph, etc.

I only saw one article specifically addressing combining the two, but also very little on server side transitioning from one to the other.

I wish there was an article on starting with HTMX and what Ajax looks like in p

I'm in a similar boat of using HTMX and finding it's 85% there, but then being stuck with another 15% that's not fulfilled.

I'm looking at Alpine.js for that last 15%.

Let's break this down a bit.

I don't think having the server render the table HTML and you injecting it is a good idea.

HTMX, Alpine AJAX and other similar progressive web frameworks work exactly this way, as do server side rendered React.js and friends.

What if the server has downtime, and returns a 200 response but with a "maintenance mode" page

If the server is in maintence mode, it should not display the web application/web page, but instead show a "We're in maintenance mode" messages.

Having it render only on a successful response and correct parsing of JSON data is more reliable.

You're comparing making a simple web page with either no secondary calls or a single secondary call using a few lines of code to writing a client side web application. It's a bit like comparing a car with a bicycle.

You also start complicating things in terms of separation of concerns. You potentially have to adapt any styling considerations in your API, for instance if the table needs a class adding to it. Overall, not a good idea, imho.

This is certainly an opinion and that works for you, but HTMX and similar actually make much of my life easier, rather than harder since all that styling, etc. can live alongside my server logic, rather than being in an entirely separate second application.

That's a good idea and actionable about the grid- I was going for "lowest effort, highest impact"

Can you say more about "info on how one can contribute"?

This is very cool. I hope it gets uptick.

I made a similar project a few years ago for non-code projects people could volunteer for online and it hasn't had very many merge requests :(

https://volunteer.onl/

The phone company would have been happy to sell you more phone lines. I knew people who had some.

But you're right that as dumb as it is, it's likely that ISPs would have charged per "device" (ie per IP address).

Before 1983 in the US, you could only rent a phone, not own one (at least not officially) and the phone company would charge a rental fee based on how many phones you had rented from them. Then, when people could buy their own phones, they still charged you per phone that you had connected! You could lie, but they charged you.

Like I said, I have mixed feelings about NATs, but you're right that the companies would have taken advantage of customers.

I'm not the OP or author, but the argument against private network addresses is that such addresses break the Internet in some fundamental ways. Before I elaborate on the argument, I want to say that I have mixed feelings on the topic myself.

Let's start with a simple assertion: Every computer on the Internet has an Internet address.

If it has an Internet Address, it should be able to send packets to any computer on the Internet, and any other computer on the Internet should be able to send packets to it.

Private networks break this assumption. Now we have machines which can send packets out, but can't receive packets, not without either making firewall rule exceptions or else doing other firewall tricks to try to make it work. Even then, about 10-25% of the time, it doesn't work.

But it goes beyond firewall rules... with IP addresses being tied to a device, every ISP would be giving every customer a block of addresses, both commercial and residential customers.

We'd also have seen fast adoption of IPv6 when IPv4 ran out. Instead we seem to be stuck in perpetual limbo.

On team anti-private networking addresses:

- Worse service from ISPs - IPv4 still in use past when it should have been replaced - Complex work around overcoming firewalls

I'm sure we all know the benefits of private networks, so I don't need to reiterate it.

I don't think it's the same error, but without a good error message I don't know.

I did manually download the models and associated them, which are great but then the audio didn't work. On the browser version, it never asks me for permission for an audio device, and on the native version, it makes a file of 0 length and then complains it can't read the contents.

My read is that the project looks very interesting, and I'd love a FLOSS replacement for Aqua Voice, but this software isn't ready for everyday use yet, at least not on Linux.

I'd love to help somehow, whether that's a donation or experimenting if you point me to somewhere.

Same with the deb. :(

Tried it with AppImage on Linux, attempted to download a model and "Failed to download model. An error occurred." but nothing that helps me track down the error :(

As a new boss who has recently started using Story Points and requiring the devs stick to tickets, I think this article points to problems that are valid, but unrelated to the issue of tickets.

a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.

That's tangential to tickets.

We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.

That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.

Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.

Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.

“Yeah, good thought, but just stick to the ticket for now.”

That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."

Ask why the feature matters? You’re overstepping.

Ask why the feature matters and you're a good dev!

But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!

Now with tickets there's an opportunity for dialog and a paper trail on decisions.

Suggest a refactor while in the code? Not in scope.

This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.

Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.

Those aren't gold plating, they're part of code quality checks that go into reviews.

The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management. Before I had tickets, developers worked on what they wanted to work on

I'm interested but I have more questions than answers.

It might make sense to provide some system for figuring out how to create the budget, and then how to track your expenses against it.

In my mind the simplest form of budgeting is so-called "Envelope Accounting", where you have physical envelopes full of money where you pull money out when you spend it.

There are electronic envelope accounting systems which retain the simplicity.

I'm a bit unsure of how this system works, where it differs, etc.

In summary, I'd love to see:

1. An explanation of how to construct a budget using your system.

2. An explanation of how to compare your spending to your budget? (bonus points if I can use my existing plain text accounting system, or at least a csv file)

3. An explanation of how to track my budget over time.

Did you read the statement they put out later that day about Musk, or the day after?

I agree this was a terrible move on the ADL's part, and there have been others, but you're essentially labeling the oldest anti-hate group "fascist" because you disagree with one statement they made.

This dismisses any concerns they raise, or if someone else says the same as them, then they too must be pro-facist.

Demanding moral perfection from an organization in order to believe that discrimination exists is a standard that I don't believe is fair to any group.

Basically, almost any time Zionists are mentioned, they're mentioned in a negative light and with genuine disinformation, such as that Zionism is the belief that Arabs needs to be destroyed. That is like saying the Civil Rights movement in the US was about killing white people.

They also position things in such a way that implies antisemitic things, such as saying that Zionism is only 200 years old, or discussing the Israel wars only or primarily through an Arab lens.

These biases around Jewish topics are small individually but large in aggregate, especially in how they present Jews and Jewish topics.

Multiple Jewish and civil rights organizations have done a more comprehensive job at discussing this, even organizations who don't usually agree on things. While they talk about "anti-Israel bias" Wikipedia articles on or mentioning Zionism (80% of Jews are Zionist) are IMHO just as, if not more damaging, and demonstrate the issue.

Most importantly though, talk to the Jews in your life about this. They will tell you.

https://www.worldjewishcongress.org/en/news/wikipedia-entrie...

https://www.jpost.com/diaspora/article-846563

https://cameraoncampus.org/blog/seven-tactics-wikipedia-edit...

https://www.adl.org/resources/report/editing-hate-how-anti-i...

https://www.standwithus.com/post/it-s-time-to-correct-wikipe...

https://www.piratewires.com/p/how-wikipedia-s-pro-hamas-edit...

The fact that my comment is -2 on HN is a great example of the problem.

I'm working on a solution to the effects of this isolation, but it's not ready for a big announcement.

Aren't you making their point though?

The ADL and other Jewish organizations have pointed out that aside from articles about Israel that articles about or mention Jewish topics generally have been editing with disinformation or that made Jews out to be the aggressors.

I agree with you that in order to believe in the ideals of liberal democracy that we must have a core belief in truth. And it's absolutely true that the Trump administration has taken a position that is deeply chilling on the issue of speech. It's clear they want to be the sole arbiters of what "truth" is and they want to use their power to manipulate the reality.

All that said, I cannot as a Jew ignore the fact that Wikipedia is not in itself neutral, and that "more eyes" does not negate systemic bias. What I've seen as a Jew is what the true meaning of marginalized minority is, which is to say that if you are truly a minority and truly marginalized then in a vote of "truth", your reality will be dismissed if it conflicts with the vast majority, and that Jews are only 0.2% of the world population.

While I brought it up, I am not debating the issue of antisemitic bias in Wikipedia[1] as anything other than an illustration of your point of objective truth being true, but also that we can't simply rely on the wisdom of the crowd to materialize that truth.

To preemptively address the issue that's bound to come up when I post this- I'm not arguing that the evils of silencing the entire Wikipedia project are equal to or a fair response to Wikipedia's antisemitic bias. I do believe Wikipedia needs to address its bias problem and that's best done through internal reform.

Two wrongs don't make a right, nor are two wrongs always of equal weight.

[1] Firstly because my point is separate, and secondly because I've encountered the exact issues I've found in Wikipedia elsewhere, which is why I'm sure I'll be voted down.

Migration/upgrades need to happen no matter the size of the service, so I'm not sure what you mean.

All that's old is new again. More than a decade ago, I inherited a Node application and was able to use many of these exact techniques inside the application.

Even moreso, I could introspect the entire application state, including providing myself a shell and modify application state within the application. Keeping a blocklist inside a simple array- no problem! And being able to run a shell inside the same process meant I could inspect and even modify the array while the application ran.

That made it incredibly pleasant to use and run.

On the flip side, upgrades can be very challenging.

In a modern web application it's standard practice to run (at least) two instances of the application at once and use the load balancer to test both, or to drain jobs from one to the other. This is relatively easy if the applications are stateless.

Once the application holds all the state in memory, there's a real challenge. That array that seemed so clever- you'll need to serialize it so it can be reloaded at initialization time. Keeping all the session identifiers in memory- be ready to dump that.

Worse, if the application is not designed to share this state with another application, you're now in some trouble. This is fine if you're running a small site with a few users who can accept some downtime, but if you're running a serious service, you'd like to have some kind of upgrade path other than shutting the application down and starting it back up again.

"I'll just share state with other application servers", you might think, and then use something like ZeroMQ to transmit state", but once you think about sharing state between application servers, you realize you'd probably be better off using a tool like Redis, and you're right back where we started.

Thank you so much!!!

I wish it supported other sites that yt-dlp supports, particularly Nebula but this is already a great start, and hopefully they'll add other sites eventually. It seems this has been discussed before.

I've been thinking about this myself. I have a few questions for you.

The first is how you organize them. With 10k videos, do you organize the files in some way?

Secondly, aside from this project, have you found a nice way to browse/watch these videos?

Thirdly, any chance you could throw your scripts up somewhere?

This is exactly the post I've needed.

I have two calendars, one on my personal server running Mailcow (SoGO) and my work calendar with Fastmail.

They don't work together- I've never found a way to get mailcow's calendar to work with other tools well, and so I spend time syncing between them semi-manually.

I've wanted to de-couple the calendar for a while but the only alternative I knew about was Nextcloud, which I think is a bit heavy weight.

This Baïkal looks great and I can't wait to give it a try. Doing this will also allow me to explore changing out Mailcow for another self-hosted mail service.

I'm a paying customer and I signed onto Aqua Voice shortly after your demo on HN.

My experience with it has been overall positive but mixed. I enjoy using it for dictation, but I found that issuing editing commands and having them recognized/executed often took a lot longer than making an edit myself (which I can't do while in dictation mode).

But as a paying customer, seeing you go in this direction is somewhat sad/frustrating. You're abandoning the product I use, and you're saying that if I want to see my platform supported, I or someone from the community has to provide it- for a fully proprietary paid application.

I understand that I'm a minority user, but it's a bit disappointing to read this.

There are arguments one can make for benefits of surveillance capitalism, but you used the exact right word, "net". We can't say "Is the a benefit or not?" but "Is there a net positive", and that's a different question from is there any positive.

With that, let me outline where I think proponents would argue there is a benefit

- Consumers get "relevant ads".

If an ad company knows you're in the market for a new grill, it's better for them to show you advertisements for grills than for soap. The argument made here is that the consumer wastes less time, has less of an issue with ads (since they're relevant) and is better informed (arguing that ads are a form of information).

- Advertisers waste less money

The argument here goes that an advertiser who puts out an ad on TV or a magazine only has some vague notion of who the audience is. If they know who they want to target to buy their product, they don't to spend money advertising to people who aren't going to buy their product.

- It lets smaller advertisers come in for a niche audience

Let's imagine that your product or service is very niche. You're likely to have less resources to spend on advertising, and you need to make your ad spending count. With surveillance capitalism and targeted ads, you can reach your target market.

I don't personally view these benefits as outweighing the net negative of the incredible amount of information collected on people and the way this information is used not only to get people to spend more (since that's what advertisement is) but also for psychological and even political manipulation as we saw in the last US election where different people would be shown customized ads to stir up their fears and doubt.

This is IMHO the right angle.

Advertising is virtually impossible to stop, but more than that, is not inherently evil. Most countries include laws on how you can advertise. For example, you can't lie and make a claim that your product can't live up to, you can't use certain words or phrases, and you have to have disclaimers in some situations.

In the mid-90s when Yahoo was a young company, they had a simple advertising model. The ad would be placed next to the section of the site relevant to the category. If you were searching for watches, a watch ad would be next to it. The advertiser would know how many times the ad was served and how many times it was clicked on.

They didn't have deep demographic data like they do today.

The surveillance capitalism model is the predatory model. Advertisement is only one part of that industry.

When I was in college, in 1996, several computer science professors told me I was playing with toys and no serious organization would use Linux as an operating system.

In 1997, I asked a math professor about a statistics program, and he said R would never be used for real work.

In 1998, I was told that sure, I could learn Python if I wanted, but I should learn Java, but if I insisted on a scripting language, I should stick with Perl.

I don't use tools because I think they're popular, I do what I enjoy.

Also you didn't ask me why it might be easier for me to learn the lyre, which has to do with physical limitations I have.

Awesome!

This looks super cool, and very similar to a need I have, except I'm not learning the guitar.

I'm learning my first (serious) instrument and I've decided on the lyre, since it's similar to other string instruments (guitar, ukulele, traditional harp) but a bit easier.

Will you support other instruments for lessons, other than the guitar?

Let's take what you said apart a bit;

- Doctors take busses to work: I lived in NYC and regularly saw doctors take public transportation. I also saw lawyers take public transportation, and many other professionals do the same. Why not doctors?

- "in France where a cardiologist makes less than a dental hygienist in Ohio."

As someone who lived briefly in France, and who grew up with a French parent, this is either untrue, or requires a lot of context in this apples to kiwis comparison. Show me data, and also don't forget to count all the income streams a physician in France has, and the fact that they don't carry the same debt as an American doctor, and compare their income to a dental hygienist in the same region of France.

- Meanwhile, patients complain that a 15-minute consultation in the U.S. costs $300. You’re not paying for the time — you’re paying for the privilege of certainty, of safety, of knowing your doctor passed through the most rigorous, exclusive system in the world.

Between my wife and myself, we've lived in five countries. The skill of doctors in the US is not any better than doctors of the non-US countries we've lived. The idea that US doctors are "the best in the world" is just nationalistic.

I worked in the US medical billing industry, and the idea that the US system is efficient or even fair is completely bizare to me.

I current reside in Canada, where I regularly argue the health care system is broken, but compared to the US, it's still heads and tails better for the vast majority of Canadians. The Canadian system needs major reform to bring it to the level of eg a European nation, but the US is cruel. It's cruel to patients, who are regularly prevented from getting care due to financial issues. It's cruel to require patients pay so much in fees, and risk bankruptcy due to their health. It's cruel to doctors too, to force them to work with the sword of Damocles over their heads of crippling debt, an inhumane insurance system, endless amounts of paperwork, stressful schedules, etc.

The cause of this miserable state in the US is clear, and has been for at fifty years.

Oh and I saw the doctor earlier this week for a followup. I didn't bring my own stethoscope. I also didn't bring a credit card.