I've never understood the appeal of hot-patching and full process image save and restore. Yes, this technology is neat for some use cases, but as a fundamental way of computing it's broken, because it throws reproducibility out of the window. Reproducibility is everything in complex systems, and being able to reset and start fresh is powerful. Evolution figured that out as well. It's why basically all species propaga…
As soon as one works on a non-trivial piece of software and has a team >2 SCM becomes important. There was one SCM system for PP Smalltalk if memory serves right called Envy but it was quite expensive. But even more important than SCM is a module/library eco system. We can’t trade without reproducibility. Without it we are destined to re-invent the wheel. There is value in reinventing wheel - it is entertaining and s…
Is true hacking dead? What we lost
101–110 of 194 posts
Re: Is true hacking dead? What we lost
#102There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…
Re: Is true hacking dead? What we lost
#103Some environments like Pharo Smalltalk are simple enough to dig down to see how stuff works, and I would add simple Lisp implementations.
When I first started using Ruby and Rails, I kept the source code to Ruby and for Rails available for perusal and it was more or less understandable. Not so much now. Complexity.
I think that the Racket ecosystem will get more hackable once the codebase sits on top of Chez Scheme. Racket is well documented: 18 months ago I wanted to import trained weights and biases from a trained Keras/TensorFlow model into Racket and implement a runtime - fairly easy to do with good documentation and good library support for fast linear algebra.
Too bad that more people don’t spend more effort on hacking activities because really understanding tools, modifying code, etc. is fun and I would argue a good career move.
EDIT: added 1 word for clarity
Re: Is true hacking dead? What we lost
#104Earlier quoted context omitted.
> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.
A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.
Re: Is true hacking dead? What we lost
#105I don't think true hacking is dead, its just lost in a sea of non-hacking. The number of students who could write code in my high school of 2000 was perhaps 35. Those 35 were amazing because they had to work to get access to a computer, so we had already eliminated everyone who was just "oh that's too hard". Of the 35 perhaps a dozen kept at it beyond one class in BASIC. In my daughter's similarly sized highschool 40…
> Compulsive puzzle gene Did you observe this in _all_ of the mentioned 35 students in your high school? Do you think that an aptitude for puzzles is a de-facto pre-requisite? I know that it shouldn't be, but I'm wondering if you have actually met people who are not good with puzzles but are extremely good when it comes to making a computer do things.
Re: Is true hacking dead? What we lost
#106Earlier quoted context omitted.
> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.
A puzzle will more often than not have one right way to do it, unlike real engineering problems which are made of trade-offs, and that one way is unintuitive, otherwise it wouldn't be much of a puzzle at all.
Re: Is true hacking dead? What we lost
#107There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…
Re: Is true hacking dead? What we lost
#108There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…
Please use Godot rather than Unity. Hackers and educational institutions should not be advocating for proprietary software that locks in its users.
First it's "don't use Unity", then it's "don't publish your Godot game for Windows", then it's "don't publish your Godot game in a form that requires proprietary graphics drivers", then it's "don't allow your game to run on Ubuntu", and so on. There's always another step to achieve ideological perfection.
Perfect is the enemy of done. Getting stuff done is the important thing.
It's much better to raise kids knowing that they can make their own games than not. If that's easier to do on Unity, then that's the way to go.
Re: Is true hacking dead? What we lost
#109There was a time when I used to fret that the era of tinkering was coming to an end. Crypto was going to be illegal, they were going to put DRM on speakers, and our computers are designed to be completely locked down to the degree that you can't even add more RAM to a MacBook Pro. However, I think that the rise of Linux, Raspberry Pi and Arduino, OSS and Github and massive package repos for every language, Adafruit,…
Hacking is just interesting only if you are not following any "tutorial". Today you can run an embedded linux under 10 minutes with less that 20 bucks with a RPI by reading some tutorial or watching a youtube video. What's the fun about that? I remember too hacking my commodore and the only help I had was just a book in a strange language (english in my case) and my dad (he was into 8086 at that time) when I was a ki…
You can always grab a book (and a manpage, and a sample config) and do it the old fashioned way. It will take longer, but will teach you more.
Re: Is true hacking dead? What we lost
#110Earlier quoted context omitted.
Puzzles don't interest me much, but composition, building and designing things does. When hiring engineers, I sometimes worry that too much puzzle-orientation shows a bias towards "clever" solutions - and complex code - where not necessarily warranted. There's definitely a place for that kind of focus, but it's usually quite low down in the stack, and that's increasingly far away from business value these days.
> complex solutions Puzzles aren't really about that. It's about making a model of a problem and finding solutions to it. Complex solutions are as bad in puzzles as in any other area. Not sure what you mean by "clever" (maybe "clever" as in unreadable code). Sometimes you come to an aha moment and realise that you can solve something in a trivial way, aka clever way, and that's a desirable event.
The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should.
There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.