andrewrothman

I like to save the best / most interesting links I come across as I browse the web. It can come in handy to pull up a blog post I read a while ago or remember some new sass product or developer tool I wanted to check out. I'm using https://raindrop.io now which works great for this.

When I looked into it I was surprised that browsers don't have this kind of bookmark management built-in. I'd be very happy with two small additions to browsers: (1) display by / sort by date added and (2) a small separate freeform text box for notes (so I can describe why I saved the link).

(Optionally it could be nice if browsers adopted some standard sync mechanism for bookmarks, maybe based on WebDAV like the Floccus extension).

Then again, these dedicated external bookmark managers do have nice features like tags, search, and offline downloads or page screenshots. Those are all great!

Linkwarden looks like a nice product. Looks like it would tick all the boxes for my use-case and the design is pleasant. I like that it's open source and has a fair price for the hosted offering. Maybe I'll give it a try!

This might be of interest:

RFC 8984 JSCalendar: A JSON Representation of Calendar Data https://www.rfc-editor.org/rfc/rfc8984.html

It seems like the ideal approach would be "proving" syntax proposals by implementing them in a preprocessor first and then later trying to standardize the syntax if it gains traction. It sounds like there are technical reasons for why that didn't work for the case of SCSS-like nesting, which is disappointing but understandable... if that's the case I think the right approach is to take these new proposals and "go back to square one" (preprocessor) vs. "go straight to standardizing something new".

After thinking about this for a while, I think they've been making the right move.

However, I'd like to see:

    - Xcode, Final Cut Pro, and other pro apps with full feature-sets designed specifically for iPad (touch, mouse, and keyboard)

    - A new keyboard accessory more like a laptop with a strong base like a Surface Book 3

    - A revamped Terminal.app for Mac and iPad with rendering perf improvements like in iTerm2, Alacritty, and Kitty

    - Virtualization support, or at least something that somehow runs Linux containers

    - Advanced tiling window management... maybe only via keyboard shortcuts

    - Ability to script iPad OS behavior - window management and keyboard remapping

    - Ability to run unsigned CLI and GUI apps from inside a terminal and/or launched via other iOS apps like would be used in iOS Xcode

Bonus: Unlockable bootloader to run alternative OS's like M1 Macs can.

If they did all of these I'd strongly consider buying one as my primary device.

I've been using GNU Stow (with Git) for the past month to sync some of my dotfiles between two laptops (Mac and Linux). It took 10 minutes to get comfortable with it and it works well for me.

I'm in the process of the same switch.

I've liked Standard Notes. It's really nice that it's open source and encrypted. However I ran into some instances of cross-device conflicting edits which were a bit annoying, and Obsidian's UI and Second Brain features swayed me to try it. The graph view is really cool and I realized I didn't need syncing as much as I thought.

Obsidian does seem to also have a paid sync feature (no mobile app yet). For now I've been emailing myself from my phone and taking small audio memos, then typing them into Obsidian when back at my laptop. Not an ideal workflow but it's not bad and has some advantages.

Looks great. I'd love something like this. I assume it charges over USB-C? Any chance we can get a video of the laptop in-use, and maybe a few shots of it next to other popular laptops?

Great design/hardware. Specifically the high res 3:2 display, camera privacy guard, and the weight. And the repairability / upgradability is awesome.

Thanks for your contribution and outreach! SWR has been really helpful for us at work.

Interesting article. Thanks for sharing!

My dream platform:

1. Single binary install on nodes, and easy to join them into a cluster.

2. Resources defined as JSON with comments in a simple format with JSON Schema URLs denoting resource types - I should be able to run 1 container with 3 lines of resource definition.

3. Everything as a CRD... No resources or funcionality pre-installed and instead available via publicly hosted HTTPS schema URLs.

4. Pluggable / auto-installed runtimes based on the schema URL or a "runtime" field: containers, vms, firecracker, wasm, maybe even bare processes, etc.

5. A standard web dashboard with a marketplace which can install multiple containers, vms, wasm or via a copy-pasted HTTPS URL, or a standard electron app which lets me connect to clusters or manage local deployments on my devbox.

6. Apps can provide a JSON schema with config options, which map to env vars and volume mounts and can be displayed in a user friendly way in the web dashboard.

I feel something like this could standardize even more than kube. I'd love if one system allowed me to manage AWS EC2 / DigitalOcean / Proxmox instances, as well as manage services on my devbox for daily use (like daemons, etc.)

With that said, I do like a standard format across service providers. While I do find kube complex at times, I like that something "won" this battle, and I also like the push towards containers vs vms.

I'd love to see kube start pairing down and innovating toward making things easier for smaller clusters. Anyone know if there are discussions about that going on, or if there are resources for managing kube in smaller teams? Anyone interested in this?

I have a Mastodon account. I just tried visiting the local timeline of a different instance, as recommended, and I have to say it was a much more engaging experience than I had had before on my account's instance.

Is there any chance for a federated interaction to effectively replace the local timeline? It'd be cool to be able to jump into a "community timeline" without that being tied to your account's "instance" (ie. using one account for multiple interests).

Thanks for the tip!

This is Aw-some.

That makes sense. Thanks for the info!

I should be clear my interest is theoretical. I haven't run into any practical issues with "crates.io" and it's been working great for me.

I think the way Go and ES Modules (Deno / browsers) represent module naming and resolution by URLs has some nice benefits:

  * decentralized module hosting

  * could be extended beyond HTTP / Git (ie. import modules via "ipfs://")

  * re-uses existing web infrastructure for namespace ownership (ie. via DNS)

  * possibility of hosting backend and frontend modules for multiple languages in a single HTTP registry

However, I do see some important tradeoffs to that approach:

  * modules may become unresolvable from their original URL (link rot)

  * cannot guarantee immutability at the original URL

  * semver support becomes a concern of the registry, and some registries may not support it (ie. the logic to resolve "https://example.com/my-module/1.x.x/lib.rs")

  * more difficult to discover (browse and search) all available modules

I see some proposed solutions to the tradeoffs:

  * proxies and dep lockfiles of file hashes to help prevent link rot and immutability

  * possibility for open source registry implementations with built-in semver support

  * central index of modules which can be searched / browsed, if modules are submitted to it

However, those solutions don't guarantee fixes for every tradeoff.

I'd be very interested in learning more about the costs / benefits of the various approaches and the Rust team's discussions on modules. I really appreciate the team's thorough approach to design decisions, as it's manifested into a really cleanly-designed language.

Thanks!

Steve, thanks for all your work on Rust!

I'd like to understand more about the arguments for and against a URL-based module naming / resolution approach. Could you point me to any past discussions on this for further reading?

This has me feeling excited for something new and interesting. I'll be watching on Monday.

Off-topic, but I read the title as "Supported on Linux distributions including but not limited to Windows". Microsoft, you know what we want.

I have mixed feelings on urbit. I think it's a really interesting idea, but it's implementation is too obscure and complex. I do, however, sympathize with their goal and appreciate the UI design of this new web app.

I struggle to see the practical benefit of urbit versus something like sandstorm.io, although I don't think that project is perfect either. With WebAssembly getting its footing, it's hard for me to justify a future platform that requires code to be written in a specific language.

What if we had a federated computing platform that ran code via WebAssembly, stored data wherever the user would like including an option for IPFS, and managed identity via OAuth / SSL certificate authorities / private/public keys? It could be interacted with via a web portal, and apps could be provided APIs to interact with other apps and the rest of the system.

I can see something like that being built to fulfill similar goals (as I understand them... I could be wrong) but using existing tech: HTTP3, TLS, IPFS, WebAssembly

Good critique. I agree about control flow and memoization. I tend to run into issues every now and then with memoization and hook "dependencies", but I'm getting better at it.

I think 1, 2 and 3 aren't really great arguments. There's always more to learn, and it seems that class components are on the way out, and are around mostly due to backwards compatibility. But it is true that a lot of legacy code uses them. I wish they'd have started with functional components, but I can't blame the team for not figuring out all of the details in advance.

I'm curious what others think. Thanks!

I really like the idea proposed here of <Spacer /> components. I always thought it was weird to assign a margin to elements of a list to achieve spacing. To maintain proper spacing it's often best to either make the top and bottom margins of each element equal, or remove the top/bottom margin from the first/last element. Both techniques come with complications.

Abstracting that out makes it easier to achieve a commonly used layout. Not quite sure the best way to implement this, but I'll definitely be giving the idea a shot.

https://seek-oss.github.io/braid-design-system/components/St...

https://github.com/seek-oss/braid-design-system/blob/master/...

I use Insomnia as well. There's a few Postman features I miss, but I like that it's slightly less heavy, and I like the Insomnia UI a lot better. They've been responsive to my feedback over email, and I think they have the right idea.

VS Code proves that a developer tool with nice UI, lots of features, and workable performance is possible. What's yet to be seen is if it can be done to the same degree by a team without the resources of Microsoft or Slack.

I'd love to see Insomnia implemented as a PWA. I would bet there's some technical challenges involved there, but PWAs have the advantage of re-using the browser instance I already have running to do my work and read HN.

I commented about this in a different thread about the same topic earlier today, but I'll post here as well.

I can understand Apple's decision to do this, as there's a lot that can be improved about offline storage on the web:

* asking for user permission (i've seen demos try to exhaust the users' storage, and trackers can use this to invade privacy) * async writes and reads

However, making a change like this with no suitable alternative leaves PWA developers stuck in a hard place. I'm not sure what can be done in the short term here.

There's a few web specs that address these issues. I'd love to see them come further along, and maybe improve things for developers and users in the long run. If anyone knows, is there anything that members of the community can do to support these efforts?

https://chromestatus.com/feature/6428344899862528

https://wicg.github.io/kv-storage/

https://chromestatus.com/feature/5715811364765696

https://storage.spec.whatwg.org/

Off topic, but how is this experience using the Surface Pro X as a PWA machine? Does Windows / PWAs work well in tablet form? I was thinking of switching to a similar setup and using it essentially as you describe. Seems like it could be a really lightweight and simple computing environment similar to Chromebooks but still allows you to run traditional Windows apps as well if you need.

This is a serious problem for modern web experiences.

"After seven days of Safari use without the user interacting with a webpage on website.example, all of website.example’s non-cookie website data is deleted." (https://webkit.org/blog/9521/intelligent-tracking-prevention...)

Granted, this could turn out really well if the industry adopts another standard which requires user permission, overcomes this limitation, overcomes the existing limitation of LocalStorage on iOS getting automatically cleared when a device is low on storage, and overcomes the problem of sites being able to use up a lot of storage on users' devices without their knowledge.

I'd be very welcoming of such a standard. These could be good future replacements if the industry can adopt them:

https://chromestatus.com/feature/6428344899862528

https://wicg.github.io/kv-storage/

https://chromestatus.com/feature/5715811364765696

https://storage.spec.whatwg.org/

I have mixed feelings about Solid. I really love the ideas behind it, and having Tim Berners-Lee (big name in tech) at the helm is a huge plus. However, I have some trouble with some of the technical choices, like RDF/Turtle. Given that most web developers are familiar with JSON, and many web APIs / services talk JSON exclusively, I feel like that should be the default recommended choice. Given that there is a lot of semantic web data already in RDF, I think that format should be supported, but not encouraged going forward.

I also think it's clear that Google and Facebook are not going to want to give up control of this data, and are highly incentivized to provide the best and cheapest services they can to keep users on their platforms. People are used to keeping their stuff in Google Drive, and wouldn't move it unless there was an easy way to do so and a good reason to even think about doing that.

I'm excited to see where it goes though, as centralization is a big problem on the web today. I try to self-host my own personal data but it's so hard to work with it in nice consumer apps. For example, I'd love to see CalDAV and CardDAV supported in Android, but for now I need to use DAVx⁵ to sync my info, and it doesn't seem to show up in Outlook for Android after years of requests to Microsoft for the feature.

I'd really like to hear other thoughts on this, as I'd love to see Solid succeed. Anyone working on Solid in this thread?

Both OpenGL shader code and on-device ML can be done in React Native. However, you likely won't reach full native performance today.

https://www.youtube.com/watch?v=1HYnrdKEVMU https://www.youtube.com/watch?v=LbcuLfrt8XA https://heartbeat.fritz.ai/image-classification-on-react-nat...

You're right there will always be a very high demand for native engineers to build the underlying bridge code to back these capabilities. As cross-platform tools gain new bridged capabilities and become faster (https://engineering.fb.com/android/hermes/), as they have been slowly, I think the use-cases where using something like React Native or Flutter is possible and makes sense will grow.

My approach to this is pretty simple. For existing systems, don't refactor from one to the other unnecessarily. If you do decide to refractor, do it in small steps, one piece at a time.

There are huge advantages to both patterns. For newer systems, if there's a clear enough split such as "backend" and "frontend" (where frontend is a statically-hosted SPA) then it could be advantageous to keep the codebases and deployments separate.

If data is shared between services, then keeping the code to interact with the data all in one service is likely most useful.

I like to use a few services, with one often ending up being the large "monolith" potentially with a few supporting microservices on the side as it makes sense. "As it makes sense" means that the service has a specific individual encapsulated concern. Billing could be a good example, depending on how it integrates with the rest of the system.

I find microservices very useful to encapsulate independent concerns and for experimentation (don't want to rewrite the whole app using some new tech, but the billing service is small enough to give it a shot). The main problem points are the glue that holds it all together, duplicating code shared between services, and changing apis / data schema.

Ultimately, it's best to know what you and your team is/will be most comfortable with managing based on everyone's skillsets and the product at hand. If you spend time to understand the differences between the patterns in practice, and remain realistic about the advantages and disadvantages of both, you can arrive at an informed decision that works well for your team.

And lastly, make sure you pick something and then build your product. These details don't mean anything to your customers. If you made the wrong choice, you'll know when it's the right time to switch.

Not sure why there's so much negativity in this thread. Thanks for spending the time to improve this. I love that KDE can show notifications from my phone via KDE Connect. It's not without its problems (the design could improve, and I'd love support for android quick respond actions if they're possible) but overall seems like great work.

I'm not sure if the pun was intended, but if not, it would've made an excellent joke.

Not to hijack the comments section, but a little while ago I made a small VM for educational purposes in C. Heavily commented ANSI C with example programs and documentation. I figure it might be of interest to others in this thread.

https://github.com/andrewrothman/SmallVM