adkadskhj

I dabble in "life storage" and your comment made me think that some sort of executable shipped alongside backup locations to read the data, if in some deduplicated backup form, seems valuable.

Eg Camlistore/Perkeep had the premise of using JSON to store data. However some random person isn't going to write code to parse all that data, pull files out, etc. A lifeboat .exe might be interesting.

Though doing it in the most simple, least configurable, least breakable way seems.. necessary. Yea some baked in UI would be cool, but more moving parts means less likely to work.

`

Heck if it's a general purpose web app - ie not only Chrome, maybe give Tauri[1] a try?

[1]: https://github.com/tauri-apps/tauri

How useful would that book (IPv6 Address Planning) be to someone not working specifically in networking/ops? I like developing applications and i manage, of course, my home network.

I'd love a book that gives me everything i need to know about IPv6. From justifications, to things to know when working with it, implementing it, using it in my local network, etc.

I don't perhaps need or care to learn it at a super low level, but i do want a complete understanding of it for my specific use cases. Applications and home networks, i imagine. For a novice in networks, to be clear.

Thoughts?

Man, a personal hosted VPN for all my junk is my dream. Can't wait to get something selfhosted, tail-scail-like setup. Something i can get into from anywhere and work from anything. I'm tempted to order a bluetooth keyboard like this post just to have it in the car and be able to work from my iPad/iPhone in a pinch (assuming internet).

For someone wanting an easy, at home VPN for setups just like in the blog - is anything on the market competitive with Tailscale's UX? Ideally there would be no proxy, no VPN hosted on DigitalOcean that i fear being a weak point.. Instead, i'd like:

1. A redirect hosted on DigitalOcean, acting as a self hosted DynIP. No security issue here i'd think?

2. After hitting my real IP, connect to a VPN on a predetermined port.

3. Get access to bells and whistles now on the priveledged network. Bonus points if i could assign DNS entries like `ssh me@workmachine.fake` or `http(s?)://videostreaming.fake`

Tailscale makes me a bit nervous, as cool as they are i'd prefer entirely self hosted. Though i may give them a try just to experience this UX.

edit: https://blog.tonari.no/introducing-innernet innernet might be what i'm looking for

Hash Map/Set keys is a common one, for example.

So i agreed with you until:

> I'd certainly classify that as addictive behavior -- i.e. when a healthy young man is more interested in what's on his phone than he is in the attractive woman sitting across the table from him. Something is very wrong there.

We can definitely debate online life vs "in the flesh" - but it seems small minded to me for you to suggest someones preferences for experience are only the result of unhealthy addiction.

Many would argue your allowance of modern life, from TVs to cars to in city restaurants/etc. That you (or that person, i guess) didn't make a home cooked meal, or go experience nature together - to be an addiction to the modern and lacking in down to earth, honest and real connections.

Not that i agree with any of that of course. My point is that i think there is a perfectly valid possible course where someone prefers to experience their life in cities, in the woods, or in more virtual spaces.

The reality though, and where i agree with you - is that i don't think we actually have a virtual space that _isn't_ fueled entirely be addiction. Powered by highly financed and motivated teams of people.

I just think we need to be cognizant of alternative life styles. Just because commonly certain lifestyles result in unhealthy behavior doesn't inherently mean that lifestyle shouldn't be followed at all. If that was the case i think this argument should probably switch to avoiding much of modern life. As it is full of unhealthy habits and poor balances. We'll be living in the woods pretty soon if we can't recognize the possible healthy and balanced ways to live in the unhealthy-unbalanced minefield that is so many alternate forms of life.

I don't know much about Starlink, but isn't one point of Starlink that eventually it could even beat wired connections for distance latency? Ie it's a shorter and more direct trip to use Starlink to get from US West to US East, for example.

Though this is quite a ways out i imagine.

Best of all this idea works in current tech, and can get even better with future tech when Starlink starts going Satellite <-> Satellite, avoiding unnecessary land hops.

I'm interested in Starlink for all use cases, once they get more satellites up.

It's not a security risk. The security risk was removed, and the provided feature is an expensive workaround to avoid the security risk.

I gave an example here: https://news.ycombinator.com/item?id=27909949

But in addition to that, 1-3 seconds per click is horrible imo. I have to literally pause, and slow down my workflow, because every input (navigation click) takes 1-3 seconds to load? That sort of delay starts to drag on users, imo.

Wasn't JS based UI's supposed to _lighten_ the load? Make web pages faster because they could just ask for the data that changed? This feels like such a massive step backward from simple HTML, like HN.

1-3 seconds being good, or even okay, is abysmal to me. Especially when the full page isn't needed, just a handful of data. Something is fundamentally broken with this version of the "modern web". And i say that as a web developer who loves complex frontend technologies. But to me if the user isn't getting a faster response, the frontend tech would be better off as plain HTML.

You're right, i'm sensitive to load times and exaggerated by approximately 4x.

I just (loosely) timed it, it took ~10-12s to open a backlog selected issue card _with cache_ from refresh. I used that example because it highlights the list i gave before.

1. The page loads, a bit slow in general.

2. The dom has loaded, so now backlog issues are loading.

3. The backlog issues are loaded, so now the selected component opens.

4. The selected issue component starts loading data.

5. Your data is now finally visible.

The ~10-12s is loosely evenly spread through the entire steps 1-5. This is on Jira Cloud, no "toaster NAS" unless you want to blame Jira Cloud for running a toaster, in which case i'd agree.

The problem in my mind isn't the servers. Opening the network tab, you see requests responding a bit slow, maybe 50-500ms, but not _terrible_. I'd like to see all requests below 300ms personally.

The problem is the UI design. Everything executes dynamically and sequentially. The URL indicates exactly what sort of page i want to see, but nothing is loaded until the JS loads, renders, makes a request for whatever data that individual component needs. Any sub-components to this then get rinse and repeat once they are actually loaded.

When you stack components on components on components that all need to sequentially load data a 1-2s load time starts to stack up, fast. And best of all, network requests are slowed down by how fast your DOM renders? Ugh.

> Sometimes I don't understand what's going on in the heads of the people thinking this stuff up :/

So this post made me look up[1][2] COOP/COEP, but as far as i can tell this seems to be a security measure. Seemingly because they don't know, at this point in time, how else to enable shared memory in WASM without this limitation.

So what in your mind could have been done better? I agree it really sucks having your WASM apps live in two camps, single and multithreaded, but it seems like we, as users conceptually have two choices:

1. Don't get shared memory at all. Or, 2. Get shared memory in limited scenarios

#2 still seems better than #1, no?

Or do you perhaps think the performance Opt-In is overly aggressive. Ie if we just enabled shared memory always we'd reduce the WASM split with minimal issues. Alternatively we could do the reverse, Opt-Out, such that for resource constrained environments the phone/whatever could connect to `mobile.example.com`.

[1]: https://web.dev/coop-coep/ [2]: https://www.youtube.com/watch?v=XLNJYhjA-0c&t=4s

I could agree with you from a UX-flow perspective, but the tech is so shoddy that i loathe it. Everything is a "web 2.0" monstrosity of load times and popin. Open the wrong link and it takes you 40 seconds for components to popin, pull data, render, move to the highlighted component, it to popin, pull data, render, and finally you get what you want.

The UX-flow might be good, not sure, but the tech is so bad it actually inhibits users. The use of independent components might be neat when loading a Jira card from Bitbucket pull requests (which works), but it makes loading Jira cards from... Jira, terrible. Imo.

Man, i feel like i'd miss so many interesting topics. Do you think this same goal might work if you limited it to, say, 10 bookmarks?

Survival of the fittest, you always compare it to the rest and if it's good enough, it goes in and something else comes out?

Wow i'm going to have to try this sometime. That looks impressive. Anyone here try it before? How well does it work?

This looks cool! I'm writing an immutable data store, with my own hashes as IDs; I wonder how viable it would be to use IPFS CID's as my IDs?

I expect the trouble there would be how the data is chunked. If IPFS disagrees about the chunking we would have different CIDs.

.. also i'd need to implement all of this myself to get it in Rust. Hmm.

I don't know this field, perhaps my bar is low because of Python lol, but Go's GC has very short GC pauses. So short that it makes non-GC'd usecases less attractive imo.

My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)

Yea, i can see that. As much as i dislike Go these days, their GC is impressive as hell. I can imagine future GC's will learn a lot from Go.

Is there a reason you'd not just throw RC-like solutions on it? Ie the GC is basically going to employ a handful of techniques with overhead like RC, memory Arenas, etc - which you could also use in Rust.

So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?

Curious, why do you want a GC'd Rust? I imagine there's something about Rust that you feel would be improved with a GC?

> You should hire people who know a statically typed language and prepared to learn Rust.

I believe i said exactly this. Specifically i said:

> We're hiring devs who want to use Rust.

Which seems clear to me. My edit also addresses new Rust devs. Our requirement is that you want to work in Rust. Which shouldn't be shocking or controversial.

> I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.

I think i addressed this in my edit. We are not doing this.

Your 25k cards interest me. I've long hoped to merge the concepts of knowledge base and retention. I love knowledge bases, but i want them to aid and augment my natural retention.

Can you speak about how you use the 25k cards? Do you feel you retain them all?

At first glance i suspect you're using your 25k cards the way i envision my ideal knowledge base setup. A store of information which exceeds my brains capacity, but which i can choose a slice at which i want to transfer to my brain. Ie choose a deck of cards and working on that to transfer (learn) the material again.

> But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.

Yea, this is our opinion. Our options are limited due to the smaller talent pool, so the time it takes for devs to "spin up" is something we consider. We can't hire a full team of devs who take 2 months to spin up. We can, maybe, do 5 young devs and 5 seasoned devs.

I've personally found that devs who have experience with C++ are almost a direct shoe-in. They know all the concepts and the transition seems easy, especially since they're already interested in Rust. Having hired a few dynamic language folks though, they have a higher barrier to entry with Rust. A lot more concepts to learn.

This statement is so odd. So we should hire to bring on people who want to work in PHP, and then force them to use Rust?

We have a large codebase in Rust. We're hiring devs who want to use Rust. Why is that "doing something wrong"?

edit: Maybe you think we require full Rust mastery on hiring. We don't. Though we make it clear that work on a Rust codebase is ~~expected~~ required, and familiarity with generalized concepts like static/dynamic dispatch are important. We hire young Rust devs all the time.

For me it was things that aided user(dev) experience, and that was primarily things like iterators, enums, and functional patterns like maps (in the robust stdlib), good crate ecosystem. That made a huge DX improvement for me because it was just so applicable in so many scenarios. And to top it all off, i got the DX of things like Iterators with usually zero usability hit - Iterators themselves are fairly complex, at least in the generic param context, but Rust encapsulates that complexity so well that you rarely see it. You just Iterate and gloss over the fact that it's actually really complex.

Fwiw it can compete in a lot of areas to a lot of languages. It doesn't represent a need to replace, say NodeJS or Python with Rust, because those languages don't typically have safety issues. However Rust offers low-level benefits with many high-level abstractions. It has lower level features, like generics, so the toolbag is definitely big - but that doesn't mean you always have to use the huge toolbag.

I switched from Go because i wanted more language features. Rust isn't a competitor to Go imo, but indirectly it was for me. I never use C, and while i could use C++, i ultimately wanted a good dev UX. I chose Rust for my developer experience, not because it was a "better C/C++", of which i don't need.

Disclaimer: Rust fanatic

Sidenote, i think a lot of the tech crowd forgets how much industry will lag behind popularity, for a whole bunch of good reasons. My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust. We would have a ton of candidates in Python, JavaScript(Node), even Go. Hell even PHP.

The fact is that applicants tend to follow jobs, so you get a chicken-egg problem. New languages have a huge hill to climb in adoption and it takes years for companies to build up large codebases in new languages to result in a large job pool.

Take any previously popular, old and uninteresting language and know it well - and you can get jobs for years and years and years to come. There's just a ton of code out there written in it that needs support, extension, etc.

I always recommend learning Rust but it is certainly not a must.

There is no illusion of safety. It's 100% safe, within the code you right, if you don't use unsafe. If there is unsafe in code you use (write or shared), it's a handful of lines which you can nearly grep for it's so easy to locate.

Rust devs (like myself) aren't illusioned into believing that my code and _everything below it_ is 100% safe.

However i can positively assure you my code is 100% safe. Well, assuming no bug in Rust-lang/compiler. My _programs_ are not guaranteed to be 100% safe unless no unsafe is used, but Rust lets you know for certain what is safe, and what is unsafe.

The point isn't absolute safety in your program. The point is absolute safety where you think there is absolute safety. To strictly know what is unsafe. And to reduce the total lines that are unsafe.

edit: I'm confused by the downvotes, what is incorrect or controversial about this?

Well damn, i had no idea about Wez. I really miss Ligatures with Alacritty, so i should give Wez a try. Thanks for the link!