It's not about the boat or the cloud. Yes, they are self-imposed restrictions, but not the actual point the author is trying to make. The message I got from the text was that all these modern systems we use hurt the preservability of software. The text was about the author's journey in finding a solution for preserving their software for generations to come. A solution that if everything is lost, the runtime can be recreated easily so that the actual software can be run again.
This is something that I have been thinking about myself a lot and it was interesting to see that the thought-process has been similar with LISP, Oberon, Smalltalk, Forth etc.
It's like a carpenter creating his own tools before building a dining room table.
I believe the author writes code as an artistic outlet. They use the word beauty/beautiful 12 times, the word love 8 times, and little (in a cute diminutive way) 10 times. The expresses a relationship with coding that most people don't have. It would be like an author expressing love for a pencil. Some may agree, but many would say "its just a pencil, the words are what matter." In a similar way programmers may say "its just a language, the features are what matter." Even then, Forth is chosen in the end for completely stylistic reasons.
Even the nostalgia factor for choosing a Forth is contrived. There are plenty of portable, modern languages that will likely be runnable for decades. Lua is embeddable and will likely be put into new systems for decades, and can run on low power hardware. But Forth is ancient. Its like learning calligraphy. Either you are in a niche, or you just love doing it. But no one uses it for the daily correspondences, they have messaging apps now.
I do agree that everything being connected to the cloud definitely excludes people and places. And that place may be anytime in the future. But you can combat this with more modern solutions.
> There are plenty of portable, modern languages that will likely be runnable for decades
I'm actually not sure this is true. There are certainly a few quite venerable languages that will be around unchanged for decades (i.e. Java).
I wouldn't however take the bet, that, say, Go or Rust will be able to compile code written now, on whatever the current compiler version is in 2035. I certainly wouldn't take the bet that you will still be able to download the correct dependency versions from a package manager after 10 years...
Reading about the `left-pad` incident (almost 10 years ago itself!) gave me an incredibly strong aversion to dependencies in my own projects. I suppose that like the author, I care a lot about understanding the foundations and ensuring that whatever I build can stand on its own, as much as that may be. I think this philosophy has helped me learn a lot more than if I had just focused on “build as fast as possible”, but definitely limited the “amount” of projects I’ve completed.
I love writing in C because a) it’s simple and I can understand everything that’s going on and b) I feel confident that it’ll compile just fine years from now, because that’s how that particular ecosystem has worked and likely will continue to work.
Recently, I’ve been writing new projects in Rust, which has far better ergonomics but is far more complicated and causes me to cede control to the whims of the community and the compiler. I’m sure there are simple ways to ensure that I can use the same compiler for all new platforms that will support it, but just like everything in the modern day (for both better and worse), is implicitly and explicitly designed to always be updated.
Rust has become much more stable in the past few years, but you’re right to expect breaking changes in the next ten years. I love using the language, it’s been fun to learn and I (hope) it’s helped me write far more robust code, but I’m sure in the future there will be many times where I’ll miss C.
I think my general approach to Rust (and to C++ before that) in this type of scenario, is to treat it as a "better C", and take the absolute minimum of dependencies I can get away with
You can't even get Rust of Go to run easily on a slightly older machine (e.g. try it on a OS X Yosemite machine) because all the compatibility issues. That's not even getting to all the "online" dependencies. This are two of the worst language ecosystems in this regard (I don't know anything that would be worse actually.)
No such problems with complex C compiler packages.
Hopefully the gcc Rust project can mitigate some of the issues for Rust (since everyone wants to rust-ify long standing projects these days and hence breaking backwards compatibility of the respective packages just to be "hip & trendy")
Choosing Forth isn't simply an affectation, it has some desirable technical properties:
> Forth is, to my knowledge, the most compact language allowing high level constructs. It is so compact that Collapse OS' Forth implementation achieves self-hosting with about the same amount of resources than its assembler counterpart!
It is still unclear to me what the author wants to build. The story is cool to the level hippies-on-a-boat can be, but I'm unsure of its message, apart from software requiring internet can be tricky while at seas.
Modern software stacks are usually cloud-dependent, and much bigger and more complex than they need to be, especially for offline, low-bandwidth, or low computing power use cases.
Small, simple, useful software can be written for these use cases and has ownership and longevity benefits.
Not a groundbreaking message, but a true one. And brought home by their interesting cirumstances.
Yeah. I'm skeptical that software made for 2 people on a boat in international waters is going to generalize to people living on land under the ongoing American situation
It's good for them, but the only person I know who owns a boat is richer than me, and I'm already richer than basically all my friends
The vast majority of people living on boats are very, very broke. You can buy an old sailboat for about the price of a second-hand car, fix it up yourself, set sail, and now you don't pay rent/mortgage/utilities...
(source: I grew up on such a sailboat, and we were broke as shit)
I agree with your first paragraph, but there are lots of basically-broke people who live on boats
Old sailboats can be had for practically (and in many cases actually) nothing. If you’re reasonably handy and willing to learn you can do all the maintenance they require yourself
Boats can be some of the cheapest housing there is, even more so if you want to live somewhere picturesque
I've met people who live on boats, they work odd jobs to buy scrap parts to fix their boats themselves and eat mostly fish that they catch. Just like travelling in general, you can basically do it on nothing if you wish.
I'm sorry but no this is fantasy, unless you plan on everything failing in under decade to actually look after your boat takes money. Even salvaging a boat that's sunk can be very expensive.
For example, a through-hull needs replacing. Sure you could find a secondhand one that fits, but you still need to have it hauled out to replace.
I have only very brief experience from once owning half of a 15 foot fibreglass runabout fixer-upper, but if you've got a 30 foot yacht then can't you just stick it on a trailer yourself? I feel like you're imagining a much bigger craft.
Very often people doing this kind of thing neglect to mention a significant safety net (e.g. parental wealth) that radically changes the kind of things you can do even when you never touch it.
It’s fair to question the funding sources of lodgings in a pragmatic way, and doubly so when one lives on a boat.
In the case of 100R, they seem to have had a lot of help from Patreon folks (per Wikipedia), though I don’t know if this was their sole source of income or funding for their lifestyle. It’s interesting that folks can live like this and share it with the world, and I don’t think that these particular folks have any ulterior motives, and I have not heard anything bad about them. They seem like they’re fairly aboveboard (pun intended).
If you go read their logs you'll find that they come across as people that aren't aware of such a "significant safety net" if there is one so even if it exists it is unlikely to have had a relevant influence on their work.
They've been excruciatingly open about their experiences and what they've learned along the way, including pecuniary matters.
> If you go read their logs you'll find that they come across as people that aren't aware of such a "significant safety net" if there is one so even if it exists it is unlikely to have had a relevant influence on their work.
On the contrary, they read exactly like people in that situation to me. How many people like that do you have experience with?
Yes, I have, and they were not as meticulously frugal as the 100r couple have been. When they've described having contact with family it's been things like this:
"We got a message from Iridium saying our account was about to be suspended. We think we may have used up all our data. We can't check the weather, but SMS still work and we're trying to get in contact with them to append more minutes. Devine's dad is also helping us with it. What a shit show. We should have purchased more, but also, I don't know how it is possible that we went through it all. We did have some issues with the device, with it stalling during some internet calls... maybe this ate up extra minutes. Either way, this situation is shit, as we don't know what's going on out there and we can't broadcast our position."
"We received a message from Devine's dad, saying that he'd contacted the customer service at Iridium and that we had indeed, run out of data. Our plan was topped up, and we're able to update our position on the live map, check emails and to check the weather — finally!"
It's been much more common that they've made friends at sea and earned knowledge and help that way, besides the business they do.
These people seem to treat it as hipster bs art and not a means to actually get work done. For real work I'd say the solution is still the same, use tech that doesn't change every week and avoid needing internet for installation such as a package repo we know won't exist a few years later.
They're building games, interactive fiction and music software, for example. Famously they've invented a rather portable platform for software development that is more like a Commodore 64 or Amiga than MICROS~1 Visual Studio.
I respect this attempt to create something principled, small and self-contained. Uxn is great as a "toy" system or a teaching resource but also as something that contributes to the diversity of ideas of what computing is/can be.
I'm skeptical about some kind of catastrophic disaster that makes popular technologies inaccessible (the pandemic demonstrated our strong impulse towards business-as-usual even when the world is burning) but having ecosystems that aren't as vulnerable to corporate capture and exploitation seems valuable in its own right.
I have always been skeptical of dependency (both libraries and connected runtime services), but there’s a balance.
There’s things that we just can’t do, without a dependency. We stand on the shoulders of giants.
Right now, I’m developing and refining a demonstration client/server app, for a future article on implementing PassKeys on iOS. I require two dependencies. On the server end, I use the PHP lbuchs/WebAuthn library, and on the client end, I use KeychainSwift.
The first dependency is a requirement. Implementing that functionality myself, would be prohibitive. The second dependency is one that I could do myself, but that would add a lot of complexity to an already fairly complex project.
The moral of the story is that I always have to justify every dependency that I use, and that justification involves a lot of figuring out the pros and cons. I’m always a bit discouraged, when I see folks throwing in dependencies, willy-nilly.
I remember once, attending a class on GraphQL. It hardly mentioned the standard at all. It was a class on the abstraction dependency (A JavaScript library. Maybe something like Pandas). The class was worthless to me, as I don’t work in JS. I wanted to find out about the standard.
I admire the approach they’re taking to dependencies. Use whatever you like to build the interpreter, and build whatever you like on top, but pinch things in the right place so that you can build an interpreter up from next to nothing
This reminds me of _why's final writing, where he discusses leaving his public persona in programming. He specifically cites the preservability of code as a reason for his disillusionment.
Code as art or political movement always baffled me.
I guess anything can be a statement about the world, and we all want our lives to have meaning, so something you poured most of your waking hours into must mean something.
But as someone that sits by a computer for the better part of 30 years I just cant find beauty in it, just sadness for the human condition. Old hardware and software do not make me nostalgic, or makes me feel like we lost anything of value. It gives me the same feeling those abandoned listening posts in Chernobyl gave me, decay, the fleeting nature of existence.
You can't fight the fact that the world will keep on keeping on, with or without you. Be a person that matters to those around you, it's the best you are going to get.
I liked reading this - permacomputing is often a nice contrast with today's world where everything is constantly improving and changing and breaking at the same time.
I wonder what "peramcomputing in action" would be when you're just trying to build a website, or a SAAS app. Those things aren't really the cool alternative dreams of 100 rabbits, but they could still benefit from these kind of ideas.
One thing that often strikes me, is that the web, despite being a huge part of the problem, actually poses a lot of solutions. PWAs and WASM offer some pretty great opportunities for portability, and WASM in particular is probably the closest we've got yet to a "universal virtual machine" (I know it's still got a long way to go)
When you really think about how unreal it is to be able to write some commands and automate stuff. Whether its a PC, a machine across the world or some other physical automation, its an entirely new thing for humans to be able to do. It deserves something other than just being functional and fiscally rational. Artistry should come into it somehow. Whats the point and wheres the enjoyment otherwise. Coming up with ways to preserve your art is definitely a worthy goal, and fear that someone will come along and buy it (or some other disaster) and deprive you of your art is fair enough.
"the playfulness of Microsoft Bob" somehow made me remember Microsoft Comic Chat.[1]
Having toons with chat bubbles somehow made the foaming at the mouth mad ramblings of all those burgeoning future reddit moderators feel a little more benign.
I've hear, very simple and elegant was Mips-1 (Mips R-1000 trademark) machines. Worth to look as it is example of modern and fast 32 bit RISC processor.
>When your connection to the internet fails and that the software locks up, that skill that you thought was yours was actually entirely owned by someone, and can be taken away.
There's a middle ground between locally installed software that fails as soon as you don't have an internet connection for the phone home, and locally installed software that can be used totally unplugged. You can stick a countdown timer within the software that allows 7, 30, 90 etc days of consecutive offline interactivity before the user needs to phone home again. Heck, if you really wanted to, you could sell copies or subscriptions to that software at varying price points depending on how many days the user expects to need - if it's a feature people want, it's a feature you can price in.
Why isn't this model more common? Mm, plenty of reasons. You need to implement pretty sophisticated techniques under the hood to deter software crackers, for one, which aren't required when you make an API call every sixty seconds to an Azure Function. For two the modal human mind really hates middle grounds of this sort. I actually suspect that some "online-only" local software implements something like this under the hood, and just doesn't advertise it, or perhaps gates it being being an enterprise feature. (I have unfortunately learned firsthand that advertising my software as "works up to 30 days off-grid" gets considerably more ire than "ah, sorry, it does require an internet connection, everything's in the cloud these days, you know how it is".)
But probably the most common reason is simply that most people don't need it! Most regular people aren't using software at all when they go off grid.
I have a deep hatred for software with x days offline capability. It's not fun to discover something won't work because someone else had a bad model of what's "reasonable" when you're doing field work in rural Mongolia or wherever. It's happened to me twice. Once I was lucky enough to accidentally discover this before leaving (PDF reader), and once while already in the field (drone software).
Now I'm a lot more diligent about FOSS for anything important.
Not much more to say. Back when I was actively doing field work as an archaeologist, I'd go out to the middle of nowhere for months. There was lots of software needed and some of it had those kinds of license checks. You anticipate and prepare for computer failure in fieldwork, but it's still irritating when the failure is caused by a person instead of the environment.
I don’t think such a middle ground is really realistic. There are plenty of apps that are just thin wrappers around their backend calls and are no more capable of working offline than I am of going without food or water. But if a program is capable of being fully functional offline for 30 days, then what does it really need to call home for, other than as a confirmation of payment?
Well, you're right it isn't realistic, that's why everything is a SaaS nowadays. That's what the second order effects of this kind of expectation generates.
>Other than as confirmation of payment
This is the wrong way around, imo. Confirmation of payment is like the #1 problem a business has to solve. If the business can't reliably turn a profit by running their software on your machine, then they will run it on their own machines, no matter how much it degrades the user experience. The end result is a hollowed out market for anything local and not offered totally for free, which sadly and ironically excludes a great deal of valuable software.
Such a rambling mess of an article (no offense.) Author just blabbered on about obscure-nothingness and nothing cohesive ever appeared. I suggest putting together one single philosophy and posting it. We don't need to see every piece of obscure info that made you believe something. It's confusing as all hell to read.
This couple IS the philosophy. Sailing and making stuff as no one even dares. I recommend reading more stuff from them. They probably know something that we don't.
Amazing read that resonated with me deeply.
It's not about the boat or the cloud. Yes, they are self-imposed restrictions, but not the actual point the author is trying to make. The message I got from the text was that all these modern systems we use hurt the preservability of software. The text was about the author's journey in finding a solution for preserving their software for generations to come. A solution that if everything is lost, the runtime can be recreated easily so that the actual software can be run again.
This is something that I have been thinking about myself a lot and it was interesting to see that the thought-process has been similar with LISP, Oberon, Smalltalk, Forth etc.
It's like a carpenter creating his own tools before building a dining room table.
I believe the author writes code as an artistic outlet. They use the word beauty/beautiful 12 times, the word love 8 times, and little (in a cute diminutive way) 10 times. The expresses a relationship with coding that most people don't have. It would be like an author expressing love for a pencil. Some may agree, but many would say "its just a pencil, the words are what matter." In a similar way programmers may say "its just a language, the features are what matter." Even then, Forth is chosen in the end for completely stylistic reasons.
Even the nostalgia factor for choosing a Forth is contrived. There are plenty of portable, modern languages that will likely be runnable for decades. Lua is embeddable and will likely be put into new systems for decades, and can run on low power hardware. But Forth is ancient. Its like learning calligraphy. Either you are in a niche, or you just love doing it. But no one uses it for the daily correspondences, they have messaging apps now.
I do agree that everything being connected to the cloud definitely excludes people and places. And that place may be anytime in the future. But you can combat this with more modern solutions.
> There are plenty of portable, modern languages that will likely be runnable for decades
I'm actually not sure this is true. There are certainly a few quite venerable languages that will be around unchanged for decades (i.e. Java).
I wouldn't however take the bet, that, say, Go or Rust will be able to compile code written now, on whatever the current compiler version is in 2035. I certainly wouldn't take the bet that you will still be able to download the correct dependency versions from a package manager after 10 years...
Reading about the `left-pad` incident (almost 10 years ago itself!) gave me an incredibly strong aversion to dependencies in my own projects. I suppose that like the author, I care a lot about understanding the foundations and ensuring that whatever I build can stand on its own, as much as that may be. I think this philosophy has helped me learn a lot more than if I had just focused on “build as fast as possible”, but definitely limited the “amount” of projects I’ve completed.
I love writing in C because a) it’s simple and I can understand everything that’s going on and b) I feel confident that it’ll compile just fine years from now, because that’s how that particular ecosystem has worked and likely will continue to work.
Recently, I’ve been writing new projects in Rust, which has far better ergonomics but is far more complicated and causes me to cede control to the whims of the community and the compiler. I’m sure there are simple ways to ensure that I can use the same compiler for all new platforms that will support it, but just like everything in the modern day (for both better and worse), is implicitly and explicitly designed to always be updated.
Rust has become much more stable in the past few years, but you’re right to expect breaking changes in the next ten years. I love using the language, it’s been fun to learn and I (hope) it’s helped me write far more robust code, but I’m sure in the future there will be many times where I’ll miss C.
I think my general approach to Rust (and to C++ before that) in this type of scenario, is to treat it as a "better C", and take the absolute minimum of dependencies I can get away with
You can't even get Rust of Go to run easily on a slightly older machine (e.g. try it on a OS X Yosemite machine) because all the compatibility issues. That's not even getting to all the "online" dependencies. This are two of the worst language ecosystems in this regard (I don't know anything that would be worse actually.)
No such problems with complex C compiler packages.
Hopefully the gcc Rust project can mitigate some of the issues for Rust (since everyone wants to rust-ify long standing projects these days and hence breaking backwards compatibility of the respective packages just to be "hip & trendy")
But that's going to be true of any package manager. You're betting on Maven existing over the same timeframe as Go.
But a go-vendored repository is buildable indefinitely, and the compiler itself is easy to bootstrap.
> You're betting on Maven existing over the same timeframe as Go.
Maven is already of legal drinking age in the USA. I'm willing to take those odds ;)
Choosing Forth isn't simply an affectation, it has some desirable technical properties:
> Forth is, to my knowledge, the most compact language allowing high level constructs. It is so compact that Collapse OS' Forth implementation achieves self-hosting with about the same amount of resources than its assembler counterpart!
https://collapseos.org/forth.html
https://news.ycombinator.com/item?id=23450287
It is still unclear to me what the author wants to build. The story is cool to the level hippies-on-a-boat can be, but I'm unsure of its message, apart from software requiring internet can be tricky while at seas.
> but I'm unsure of its message
My takeaway:
Modern software stacks are usually cloud-dependent, and much bigger and more complex than they need to be, especially for offline, low-bandwidth, or low computing power use cases.
Small, simple, useful software can be written for these use cases and has ownership and longevity benefits.
Not a groundbreaking message, but a true one. And brought home by their interesting cirumstances.
Yeah. I'm skeptical that software made for 2 people on a boat in international waters is going to generalize to people living on land under the ongoing American situation
It's good for them, but the only person I know who owns a boat is richer than me, and I'm already richer than basically all my friends
The vast majority of people living on boats are very, very broke. You can buy an old sailboat for about the price of a second-hand car, fix it up yourself, set sail, and now you don't pay rent/mortgage/utilities...
(source: I grew up on such a sailboat, and we were broke as shit)
I agree with your first paragraph, but there are lots of basically-broke people who live on boats
Old sailboats can be had for practically (and in many cases actually) nothing. If you’re reasonably handy and willing to learn you can do all the maintenance they require yourself
Boats can be some of the cheapest housing there is, even more so if you want to live somewhere picturesque
(There are, of course, significant downsides)
I've met people who live on boats, they work odd jobs to buy scrap parts to fix their boats themselves and eat mostly fish that they catch. Just like travelling in general, you can basically do it on nothing if you wish.
I'm sorry but no this is fantasy, unless you plan on everything failing in under decade to actually look after your boat takes money. Even salvaging a boat that's sunk can be very expensive.
For example, a through-hull needs replacing. Sure you could find a secondhand one that fits, but you still need to have it hauled out to replace.
I have only very brief experience from once owning half of a 15 foot fibreglass runabout fixer-upper, but if you've got a 30 foot yacht then can't you just stick it on a trailer yourself? I feel like you're imagining a much bigger craft.
On top of that, dry docks are a common free amenity in boating/fishing towns, just using the tide to do your dirty work.
They thoroughly document their lives, you could just go check whether this skepticism is warranted.
Very often people doing this kind of thing neglect to mention a significant safety net (e.g. parental wealth) that radically changes the kind of things you can do even when you never touch it.
It’s fair to question the funding sources of lodgings in a pragmatic way, and doubly so when one lives on a boat.
In the case of 100R, they seem to have had a lot of help from Patreon folks (per Wikipedia), though I don’t know if this was their sole source of income or funding for their lifestyle. It’s interesting that folks can live like this and share it with the world, and I don’t think that these particular folks have any ulterior motives, and I have not heard anything bad about them. They seem like they’re fairly aboveboard (pun intended).
https://en.wikipedia.org/wiki/Hundred_Rabbits
"To buy Pino Devine & I each got a 10,000$ bank loan. We had savings, but didn't want to be left with an empty account after the purchase."
https://100r.co/site/buying_a_sailboat.html#bankloan
If you go read their logs you'll find that they come across as people that aren't aware of such a "significant safety net" if there is one so even if it exists it is unlikely to have had a relevant influence on their work.
They've been excruciatingly open about their experiences and what they've learned along the way, including pecuniary matters.
> If you go read their logs you'll find that they come across as people that aren't aware of such a "significant safety net" if there is one so even if it exists it is unlikely to have had a relevant influence on their work.
On the contrary, they read exactly like people in that situation to me. How many people like that do you have experience with?
Yes, I have, and they were not as meticulously frugal as the 100r couple have been. When they've described having contact with family it's been things like this:
"We got a message from Iridium saying our account was about to be suspended. We think we may have used up all our data. We can't check the weather, but SMS still work and we're trying to get in contact with them to append more minutes. Devine's dad is also helping us with it. What a shit show. We should have purchased more, but also, I don't know how it is possible that we went through it all. We did have some issues with the device, with it stalling during some internet calls... maybe this ate up extra minutes. Either way, this situation is shit, as we don't know what's going on out there and we can't broadcast our position."
"We received a message from Devine's dad, saying that he'd contacted the customer service at Iridium and that we had indeed, run out of data. Our plan was topped up, and we're able to update our position on the live map, check emails and to check the weather — finally!"
It's been much more common that they've made friends at sea and earned knowledge and help that way, besides the business they do.
“Ugh, we made a silly mistake; it’s ok, Dad paid to fix it.”That is certainly not evidence against any such safety net?
These people seem to treat it as hipster bs art and not a means to actually get work done. For real work I'd say the solution is still the same, use tech that doesn't change every week and avoid needing internet for installation such as a package repo we know won't exist a few years later.
They're building games, interactive fiction and music software, for example. Famously they've invented a rather portable platform for software development that is more like a Commodore 64 or Amiga than MICROS~1 Visual Studio.
s/want/have built: https://100r.co/site/uxn.html
I respect this attempt to create something principled, small and self-contained. Uxn is great as a "toy" system or a teaching resource but also as something that contributes to the diversity of ideas of what computing is/can be.
I'm skeptical about some kind of catastrophic disaster that makes popular technologies inaccessible (the pandemic demonstrated our strong impulse towards business-as-usual even when the world is burning) but having ecosystems that aren't as vulnerable to corporate capture and exploitation seems valuable in its own right.
The world was definitely not burning during the pandemic. That is something like WW1/2, smallpox, etc.
It only lightly toasted during the pandemic. Arguably, we’re getting more actual disruption now with Tariffs and Visa tit-for-tat
Interesting couple of guys. Loved the story.
I have always been skeptical of dependency (both libraries and connected runtime services), but there’s a balance.
There’s things that we just can’t do, without a dependency. We stand on the shoulders of giants.
Right now, I’m developing and refining a demonstration client/server app, for a future article on implementing PassKeys on iOS. I require two dependencies. On the server end, I use the PHP lbuchs/WebAuthn library, and on the client end, I use KeychainSwift.
The first dependency is a requirement. Implementing that functionality myself, would be prohibitive. The second dependency is one that I could do myself, but that would add a lot of complexity to an already fairly complex project.
The moral of the story is that I always have to justify every dependency that I use, and that justification involves a lot of figuring out the pros and cons. I’m always a bit discouraged, when I see folks throwing in dependencies, willy-nilly.
I remember once, attending a class on GraphQL. It hardly mentioned the standard at all. It was a class on the abstraction dependency (A JavaScript library. Maybe something like Pandas). The class was worthless to me, as I don’t work in JS. I wanted to find out about the standard.
I admire the approach they’re taking to dependencies. Use whatever you like to build the interpreter, and build whatever you like on top, but pinch things in the right place so that you can build an interpreter up from next to nothing
This reminds me of _why's final writing, where he discusses leaving his public persona in programming. He specifically cites the preservability of code as a reason for his disillusionment.
https://github.com/steveklabnik/CLOSURE
Beautiful piece of writing, very weird, very excellent.
Code as art or political movement always baffled me.
I guess anything can be a statement about the world, and we all want our lives to have meaning, so something you poured most of your waking hours into must mean something.
But as someone that sits by a computer for the better part of 30 years I just cant find beauty in it, just sadness for the human condition. Old hardware and software do not make me nostalgic, or makes me feel like we lost anything of value. It gives me the same feeling those abandoned listening posts in Chernobyl gave me, decay, the fleeting nature of existence.
You can't fight the fact that the world will keep on keeping on, with or without you. Be a person that matters to those around you, it's the best you are going to get.
I liked reading this - permacomputing is often a nice contrast with today's world where everything is constantly improving and changing and breaking at the same time.
I wonder what "peramcomputing in action" would be when you're just trying to build a website, or a SAAS app. Those things aren't really the cool alternative dreams of 100 rabbits, but they could still benefit from these kind of ideas.
One thing that often strikes me, is that the web, despite being a huge part of the problem, actually poses a lot of solutions. PWAs and WASM offer some pretty great opportunities for portability, and WASM in particular is probably the closest we've got yet to a "universal virtual machine" (I know it's still got a long way to go)
When you really think about how unreal it is to be able to write some commands and automate stuff. Whether its a PC, a machine across the world or some other physical automation, its an entirely new thing for humans to be able to do. It deserves something other than just being functional and fiscally rational. Artistry should come into it somehow. Whats the point and wheres the enjoyment otherwise. Coming up with ways to preserve your art is definitely a worthy goal, and fear that someone will come along and buy it (or some other disaster) and deprive you of your art is fair enough.
(2022) Discussion in 2023 (123 points, 28 comments) https://news.ycombinator.com/item?id=34219654
Right. From the title, I thought it was going to be about programmer survival in the age of LLMs.
"the playfulness of Microsoft Bob" somehow made me remember Microsoft Comic Chat.[1]
Having toons with chat bubbles somehow made the foaming at the mouth mad ramblings of all those burgeoning future reddit moderators feel a little more benign.
[1] https://en.wikipedia.org/wiki/Microsoft_Comic_Chat
Annoyed every other IRC user though.
I've hear, very simple and elegant was Mips-1 (Mips R-1000 trademark) machines. Worth to look as it is example of modern and fast 32 bit RISC processor.
>When your connection to the internet fails and that the software locks up, that skill that you thought was yours was actually entirely owned by someone, and can be taken away.
There's a middle ground between locally installed software that fails as soon as you don't have an internet connection for the phone home, and locally installed software that can be used totally unplugged. You can stick a countdown timer within the software that allows 7, 30, 90 etc days of consecutive offline interactivity before the user needs to phone home again. Heck, if you really wanted to, you could sell copies or subscriptions to that software at varying price points depending on how many days the user expects to need - if it's a feature people want, it's a feature you can price in.
Why isn't this model more common? Mm, plenty of reasons. You need to implement pretty sophisticated techniques under the hood to deter software crackers, for one, which aren't required when you make an API call every sixty seconds to an Azure Function. For two the modal human mind really hates middle grounds of this sort. I actually suspect that some "online-only" local software implements something like this under the hood, and just doesn't advertise it, or perhaps gates it being being an enterprise feature. (I have unfortunately learned firsthand that advertising my software as "works up to 30 days off-grid" gets considerably more ire than "ah, sorry, it does require an internet connection, everything's in the cloud these days, you know how it is".)
But probably the most common reason is simply that most people don't need it! Most regular people aren't using software at all when they go off grid.
I have a deep hatred for software with x days offline capability. It's not fun to discover something won't work because someone else had a bad model of what's "reasonable" when you're doing field work in rural Mongolia or wherever. It's happened to me twice. Once I was lucky enough to accidentally discover this before leaving (PDF reader), and once while already in the field (drone software).
Now I'm a lot more diligent about FOSS for anything important.
Tell me more, if you're able. What happened?
Not much more to say. Back when I was actively doing field work as an archaeologist, I'd go out to the middle of nowhere for months. There was lots of software needed and some of it had those kinds of license checks. You anticipate and prepare for computer failure in fieldwork, but it's still irritating when the failure is caused by a person instead of the environment.
I don’t think such a middle ground is really realistic. There are plenty of apps that are just thin wrappers around their backend calls and are no more capable of working offline than I am of going without food or water. But if a program is capable of being fully functional offline for 30 days, then what does it really need to call home for, other than as a confirmation of payment?
Well, you're right it isn't realistic, that's why everything is a SaaS nowadays. That's what the second order effects of this kind of expectation generates.
>Other than as confirmation of payment
This is the wrong way around, imo. Confirmation of payment is like the #1 problem a business has to solve. If the business can't reliably turn a profit by running their software on your machine, then they will run it on their own machines, no matter how much it degrades the user experience. The end result is a hollowed out market for anything local and not offered totally for free, which sadly and ironically excludes a great deal of valuable software.
Such a rambling mess of an article (no offense.) Author just blabbered on about obscure-nothingness and nothing cohesive ever appeared. I suggest putting together one single philosophy and posting it. We don't need to see every piece of obscure info that made you believe something. It's confusing as all hell to read.
Not everything needs to be told in a YouTube short. Fwiw I thought it was well told and illuminating.
This couple IS the philosophy. Sailing and making stuff as no one even dares. I recommend reading more stuff from them. They probably know something that we don't.
> I suggest putting together one single philosophy and posting it.
It's right there, linked to from TFA's first paragraph:
https://100r.co/site/philosophy.html
nodejs was a mistake