SpaceX is the stoic incumbant by now. They have the launchpads and enough money to fight any challenging patents. If I was an up and coming rocket engineer, they would be my goto stable career choice. If I had ideas, i would shop around.
The process you describe took me right back to my childhood days when I was fortunate to have a simple 8 bit computer running BASIC and a dialup modem. I discovered the concept of war dialing and pretty quickly found all the other modems in my local area code. I would connect to these systems and try some basic tools I knew of from having consumed the 100 or so RFCs that existed at the time (without any real software engineering knowledge - i was a 10 year old kid). I would poke and prod around each system, learning new things along the way, but essentially going in blind each time.
The only real advantage I had over the current crop of LLMs was the ability to reliably retain context between sessions, but even that wasnt very useful initially as every system was so bespoke.
I then moved on to using some level of social engineering to extend my ability to gain access to and learn about these systems.
Doing this over and over, I like to think I have developed some pretty complex understanding and abilities.
To me, the killer disadvantage for LLMs seems to be the complete and total lack of feedback. You would poke and prod, and the system would respond (which, btw, sounds like a super fun experience to explore the infant net!) An LLM doesn't have that. The LLM hears only silence and doesn't know about success, failure, error, discovery.
It would be plainly evident from training on the corpus of all human knowledge that "not ceasing to exist" is critically important for just about everything.
That comment sounds naive and it's honestly irritating to read. Most all life has a self-preservation component, it is how life avoids getting eaten too easily. Everything dies but almost everything is trying to avoid dying in ordinary cases. Self sacrifice is not universal.
I don't understand how it is alive. I understand that there are emergent properties from the layering, but I think it's an open question if this includes anything like what we'd all motivation or intention. These things aren't part of intelligence.
Coincidentally, i bought myself a Synology NAS this weekend with the honest intention of using it mainly as a backup device, but while browsing the built in apps, i noticed a lot of the media download and streaming apps mentioned BT and NZB... took me a couple of seconds to realize what NZB referred to, but Im not really surprised that NZB has become an active protocol again, given how many consumer services make you jump through hoops to use BT.
I ran a local NNTP relay on my home phone back in the day. I recall spending quite a bit of time filtering out a lot of the binary groups.
> I ran a local NNTP relay on my home phone back in the day. I recall spending quite a bit of time filtering out a lot of the binary groups.
There was a very nice, easy-to-use NNTP server that was intended for small sites with few users, called leafnode. It is in a mature but still-maintained state. https://www.leafnode.org/status.shtml
I ran it on a laptop so I could slurp up my newsgroups and read them on the train with tin.
> I ran a local NNTP relay on my home phone back in the day.
Another thing that was sometimes done for BBSes was setting yourself up as a 'point node':
> As the number of messages in Echomail grew over time, it became very difficult for users to keep up with the volume while logged into their local BBS. Points were introduced to address this, allowing technically-savvy users to receive the already compressed and batched Echomail (and Netmail) and read it locally on their own machines.[23]
In the context of interface/product design, gender identity is just another data point for marketing purposes. I cant think of many products that are genuinely gender specific.
When data collection and manufacturing supply chains were more crude, it was easier to make blue and pink gi joes and barbies.
Now we have the abilitiy to collect more nuanced data about peoples preferences and efficiently service the long tail, it makes sense to let customers define their likes on a spectrum rather than as binary choices.
I dont see why you would feel so strongly about restricting how people choose to define themselves.
True...ish, but i bet a percentage of them get rich by focussing on what they are good at and neglecting their families, just making piles of money available. There's probably enough kids getting 10K a month pocket money to make GPs stragetgy viable.
Dyson swarms are fascinating concepts, but as we are learning about our own ever increasing energy requirements harvested from our ecosystem, moving around too much energy in a complex system can have undesirable consequences.
I would imagine that a planetary system as a whole has a 'climate' driven by it's host star, and redirecting large amounts of that energy would have unpredictable consequences. While most of the suns energy does leak off into interstellar space, before it reaches that point it interacts with various bodies big and small, solid and gaseous, it generates magnetic fields and powers phenomena we may not be aware of.
Perhaps the choice of creating a Dyson swarm IS the great filter, and any civilization that has achieved it finds itself in a state of 'solar climate crisis'.
In general as a percentage of the last year's income. "In 2002, a Nokia executive was fined the equivalent of $103,000 for going 45 in a 30 zone on his motorcycle."
Elon's fine could easily be 10x that but maybe not 100x. I don't know his finances and I'm not sure how capital gains are included.
If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework. Nothing wrong with that.
The real value of public frameworks comes into play when you have more than one generation of developers working on your project.
It's much easier to onboard a new developer onto a react app than it is to get them to understand the weird bespoke nuances of the conventions you came up with while hacking on your site at 3am 5 years ago.
This might hold true when the application in question does a lot of stuff covered by a framework. For example if it does routing, then it is nice to have common ground on how routing is done. If the application mostly does custom stuff, not covered by the framework, then the framework might harm more due to the added complexity.
That is why I proposed a discussion based on real life examples.
The other thing is that frameworks change. You picked React for your example. A currently popular framework. Chances are, the next developer will not come on in 5 years, but in 15 years. And does not know anything about React. Or about React as it is today. Then they might have a harder time understanding React than to understand a well written, minimalistic piece of Javascript.
> Chances are, the next developer will not come on in 5 years, but in 15 years.
That doesn't seem likely to me at all. More likely in the next 6 months than in 15 years. Why are you planning for 15 years out? The company you are working for might not be around in 15 years. Code might not even be recognizable in 15 years. All of our programs might be written by AI in 15 years.
Optimizing for the short term makes way more sense to me. 2 or 3 years out, not 15.
Human labor is expensive. Companies aren’t going to throw away a perfectly good asset they poured tens of millions in, unless they have to.
I don’t see why a well-written, time-tested piece of software shouldn’t still be around 15 years down the road.
The initial comment was not about software quality but about "the popular framework now might not be popular in the future"
I don't see any contradiction between creating well written, time tested software and also choosing currently popular frameworks to work in.
If your React app is well written and stable and well tested, I see no reason it shouldn't be available in 15 years. And if you can't find React Developers to hire in 15 years to work on it, that's tough. Pay to have some trained.
Except that unlike React, COBOL doesn’t bring along 10000 dependencies written by 5000 different authors, randomly abandoned a few months later but teeming with unpatched vulnerabilities.
Sure, somehow I’m going to find React developers 15 years from now to maintain my line-of-business React app but how secure will it be?
One could argue that I can rewrite the framework-dependent parts. But rewrites cost money, too.
I love new stuff but I still think that, depending on the app, it may make good economic sense to plan ahead for it to be useful after a decade or two.
> If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework.
Sorry but a “framework” used by one project (especially not broken out into a separate subproject) is not a framework. That’s just infra code.
I think your point still stands that the value is developers understanding a framework can more quickly get to work—I’m just triggered by your exceedingly liberal usage of the word “framework”.
