It's very sad to read this. Often you read comparisons from Westerners comparing UK privacy laws to China's and it's easy to brush it off as being sensationalist. But to hear that from someone living in China is really worrying.
Only yesterday I was raging at Flash for continually chewing up my CPU and RAM. I hadn't even considered setting limits on the processes. So thank you for the suggestion.
You know, that's entirely possible. I was playing around with different methods of passing data between goroutines for increasing performance and I knew one of the methods I was testing wasn't idiomatic Go. However since I wasn't getting race conditions normally i assumed that the GOMAXPROCS fault wasn't down to my shonky code.
The weird thing is I thought I'd read somewhere that said Go defaulted to a process per CPU core (like the OP has hardcoded ib this project). I'm guessing that isn't the case then? It sadly wouldn't be the first time I've misread something! :(
Whichever you're most competent in. Any of those languages (and many others) would be a suitable option, so it boils down to what you are most proficient in.
I'm interested in more information about why you decided to alter GOMAXPROCS and what your results were from testing.
I've had a play with this myself and found that it cause sporadic and unpredictable crashing (very different style of application though - I was building a webserver). However this was an earlier iteration of Go (possibly Go 1.1 but likely 1.2) so things may have improved since then, or you might have found a saner way of tweaking it.
> You are missing the part about manipulating other applications or controling GUI elements, like Powershell kind of allows via DLL interop and OLE Automation.
There are lots of command line hooks for GUIs. Want to copy data to the clipboard from the command line? xclip. Want to pop up a notification in your desktop environment's notification bar? notify-send "hello world!" etc
> As for /proc/sys, not all UNIXes have such features.
That example of mine was clearly taken from Linux - so it goes without saying that most UNIXes would behave different in that specific regard. Even so, they'd still have command line tools for doing the same thing (and to be fair, Linux does too, even with a vaguely-Plan 9 virtual file system)
> In Oberon I could pipe selected text from any application into any command that had a GUI aware type signature, for example.
Well like I said, I'm not trying to say that all REPL's are equal, but most of what you're describing is still possible in at least Linux. I'm not saying it's as intuitive nor "pretty" as it would have been on the Oberon, but it's certainly possible.
To be quite honest, most of what you've been posting on this topic has really just been elitism. And I do actually sympathise with your point as working in Bash can be a complete hateful mess at times (even without comparing it to the old Lisp machines). But that doesn't change the fact that Bash is a REPL environment.
Arguing that one is better than the other is like arguing over which colour the best. Which is why I get so utterly sick of Perl being compared with Python - they are all going to have their strengths and weaknesses so at the end of the day, the "better" language / syntax boils down to personal preference.
You don't need support for complex data types for a shell to be described as "REPL".
REPL is just a Turing-complete real time interpreter. Which means even the VBA "Immediate" panel in (as seen in MS Office) is REPL. And it means Bash is REPL too.
The question you're raising is whether all REPLs are equal. Lisp machines definitely had more control over the host than VBA does. But that doesn't mean that VBA's immediate panel isn't REPL just because a more powerful example exists.
As for Bash, that's a bit of a weird one because Bash wouldn't be much without the accompanying GNU / POSIX userland. But if you're willing to include a UNIX / Linux userland into scope then Bash has just as much control over the host as Lisp did on Lisp machines. But even without the aid of forking additional executables, Bash can still modify the state of the kernel directly. eg
Perl's pseudo-objects are, in my opinion, one of the weakest aspects of Perl. So I'm not going to disagree with you that many other languages do that one thing better. But it's not always appropriate to nest your objects that deeply anyway (in any language, that can quickly become a mess).
In my personal opinion, I prefer C-style braces over whitespace formatted blocks. Which means I find reading function and iteration blocks much easier to read in Perl than I do in Python. I'm not saying one is "better" than the other, but just offering a counter argument for how subjective language aesthetics really is.
I hear this argument time and time again and it's simply FUD. Bad Perl is no different to bad C++ or any other language with a flexible syntax. But it's also the same visa versa.
The problem with Perl is most times people are exposed to it, it's either from code golfing sessions were code is deliberately obfuscated; or when it's basically been used as a shell scripting language and thus often written by aging Perl hackers who don't care much for code cleanliness. And sometimes people just run away screaming because they simply don't understand all the regular expressions (but to approach Perl without an understanding of Regex is a little like trying to code Java without understanding classes then moaning about the weird surplus boilerplate code)
I'm not trying to say that Perl doesn't have it's faults. It has a great many problems. But to state that Perls syntax makes it impossible to write clean code, is just a daft flamewar argument.
I know this is possibly the saddest thing anyone has ever said, but the computing museum is one of my favourite places on earth.
It's a joyful place with so much old technology yet a refreshingly hands on attitude. I don't think there was a single exhibit that wasn't interactive by one method or another - which really matters when you're talking about technology that is largely at an age where kids are too young to have grown up with so it gives them a chance to play with the predecessors to their much loved consumer hardware - and it gives us adults a chance to do more than just reminisce about the fun days experimenting with emerging technologies.
I'd highly recommend that museum on it's own merit; let alone spending the day exploring the site and Bletchly Park as well.
> I would also recommend it for studying operating systems
Perhaps not if you plan of contributing code to any open source OS. Practices like this can leave projects exposed to intellectual property violations.
This is why reverse engineering usually requires more people, each who isn't privy to the previous persons source material.
Oh I didn't think it would replace HTML. For me the appeal was because VRML was the closest thing we had to the 3D rendered remote mainframe logins that Hollywood hacker films loved to show off.
Running around a VR modelled web page made me feel like the Lawnmower Man or Joey hacking into the Ellingson Mineral Company supercomputer (well, maybe not Joey specifically because he was a n00b)