They don't have syntax highlighting, Zed uses LSP server for each language. I'm sure lisps have them, the question is just to add support in Zed for a particular one.
While the detection area of the cloudflare attack is bigger I think the main problem here is that its much easier to get access to it than to cellphone towers.
I remember a number of years back when Steam started Proton thing, it didn't look very promising. Since then it evolved into an actual OS, it would be amazing if Valve could pull this off and expand Linux gaming into mainstream devices and maybe even PCs.
SteamOS is a Linux distro that originally came out in 2013. Proton is a custom version of Wine that came out later -- Proton has some added features for integration with Steam, but Wine has been around and has been working well for Windows gaming on Linux for decades.
SteamOS today bears no resemblance to the version put out in 2013. It's literally based on a different distribution, and lots of things have been customized since then.
Funnily enough Valve tried to make Steam OS happen before Proton was a thing, for some reason they just expected game developers to port their games to Linux on their own dime. Thankfully they realized that was never going to happen at scale, so Proton was born instead.
> Funnily enough Valve tried to make Steam OS happen before Proton was a thing, for some reason they just expected games developers to port their games to Linux on their own dime.
Proton is just a fork of Wine. Wine had already been around for decades, and there were other commercially-supported versions of Wine, like Cedega, long before Proton was around.
On top of that, the increasing dominance of off-the-shelf game engines was already making it trivial to "port" games to Linux -- in Unity, for example, it's often just a few extra mouse clicks to produce a Linux build in parallel to your Windows build. So lots of game developers did start releasing native Linux versions, and continue to do so.
Yes WINE already existed, but SteamOS v1 didn't have it integrated as a core feature like it does today. It was very much intended to only run native Linux titles. WINE also wasn't nearly as seamless for gaming until Valve threw their weight and money behind polishing it, which came after the original SteamOS flopped.
That's a bit light on the details, and I can't make any sense of "To use stdio even you literally need kernel-level privileges on Console.", C's stdio doesn't require special privileges to use, nor does Crystal's, afaik.
More poignant examples would be `dirent.h` and `system`. Getting access to the file system on a console, or the ability to start up a process out of band is not allowed.
Which task? DragonRuby uses a custom mruby build to target cross platform game releases so their goal is to fit the Ruby lang spec, which Crystal does not adhere to.
I honestly thought that "ruby lang spec" was "whatever Matz ruby does." The ISO-IEC-30170 standard cited by mruby's readme seems to be laughably old but I can't obviously tell if mruby is a superset of the ISO or a subset. Their use of the phrase "part of the ISO standard" doesn't help
Matz is the creator and maintainer of Ruby, yes. mruby is a subset to my knowledge, and I don't think it's 100% parity with Ruby MRI (CRuby), which is basically what the lang spec is built around to my knowledge.
The oldest Sanskrit text, the Rigveda, is usually dated to 1500 BC as an oral tradition. It wasn't written down until much later. The oldest surviving unambiguously Sanskrit writing is from 100 BC, using the Brahmi script. It actually isn't the surviving oldest Indic written language either, the Edicts of Ashoka date to 300 BC and are texts written using various scripts and vernacular languages.
Its always nice to see people experimenting with different technologies.
I'm curious about Erlang server, do you see any advantage or features that Erlang provides, compared to for example if the server was running in Python via multiple instances?
We haven't touched the distributed part of the game, but our understanding is that when that time comes, it will be easier to use the BEAM approach given that it was made for this purpose.
Given the experience so far, it seems that using Erlang was the correct choice, not only because of the above, but also because Erlang made the server implementation way easier than we thought.
I see now, you are sending messages directly to Erlang server so you don't have to worry about network sockets.
In my experience the issues with Erlang come with working with data structures, records are not flexible and there is not much one can do to abstract the boilerplate.
Having a potentially untrusted client connect to the erlang node as a c_node (which seems to be what zerl does) is not a good idea generally, as connecting that way essentially allows the client to execute arbitrary code on the server.
As far as I can tell, this is not possible at all; the serialization layer (Zerl) cannot send arbitrary code to another node. Now, assuming we implement this, I also think this is not possible due to how the server is designed; based on supervisors and child processes for user sessions.
We recently became aware that you can indeed send tuples that have fixed effects when using the supervisor behavior, so it may be totally possible and probable that one could exploit this vulnerability to some degree in our server. We plan to investigate more about it as we continue to learn more about OTP and the BEAM.
If you're using zerl on the client and plain dist on the server; the question isn't what Zerl can serialize, but what the server will process.
With stock OTP dist, there is no barrier between nodes. Stock OTP runs an rpc server that you can use to send function calls to run, which can include BEAM code to load (or file I/O to do); and even if that's disabled, you can spawn a process to run a function with arguments on a remote node without needing an rpc server at all.
I'm not aware of anyone running a limited dist to allow for untrusted dist clients. But here's an OTP response to a proposal that's pretty clearly a no [1].
It'd be much simpler to put together a custom protocol to communicate between the client and server. You could use Erlang's External Term Format to exchange data if you want, in which case you'd want to do binary_to_term(Binary, [safe]) to prevent creation of new atoms and new function references which can fill up tables and also consider that just because deserializing is safe for the runtime doesn't mean you can trust the client.
Erlang makes it pretty easy to parse sensible things off of network sockets, if you want to go more custom, too. Binary pattern matching is lovely.
Thanks for the ideas and references!
I gotta say, though, that I will be pretty sad if having to write a custom protocol turns out to be the final solution. So much more convenient to use OTP (especially now that we finally have an infinitely extensible serialization library for it; Zerl). I'm shocked such an oversight would exist in a real commercial solution which is the BEAM.
The original application of dist clustering was dual computers in a single telecom switch. There's not really a need for a security barrier in that case; anyone with access to one computer would be expected to have access to the other.
Additional applications for dist have been explored over the years, but most of them involve clustering servers; where a security barrier isn't necessary; although it might be desirable --- I've used dist clusters where some people had access to only certain types of nodes; bypassing access control using dist clustering was certainly a possibility. Bolting security onto something designed without it often is pretty challenging. Especially if you want to keep all the existing applications working.
As another commenter said, OTP messages are meant to be between processes in the same privilege zone. That said, using a custom protcol via a good library can actually bring benefits relative to core OTP stuff.
For example, several of the gRPC libs I've used for Erlang/Elixir are pretty low-cognitive-overhead to use, and they come with all the added gRPC goodies: RPC semantics are described in one place rather than ad-hoc throughout code, protobufs have at least a documented (if not actually good) process for upgrades and backwards compatibility, multilanguage gets easier (even if your second language is just a tiny sliver of "dump protobufs into a database/Jupyter notebook/Rust program occasionally for offline reporting").
To be clear, this isn't a paean to gRPC; most of those features are table stakes for an IDL-driven protocol definition. Just saying that you do get some things in return for giving up the convenience of OTP, if you pick the right tools.
I think this behavior can be fixed by properly using something like `lib_chan`, but we needed something that worked first for our Func Prog Sweden demo.
Indeed a malicious client can craft an brutal kill message as long as it knows the PID a process (either a worker or a supervisor) for instance.
Take a look at Erlang's "parse transforms" which would allow you to implement some syntactic sugar. That's what is used to implement qlc, the query language for ETS/Mnesia - that one adds new semantics to list comprehensions, but you can modify any part of the syntax you want.
Also, Elixir supports macros and infix operator overloading - have you considered using it? If you know Erlang's stdlib and BEAM, switching to Elixir (and back) is almost painless. Not sure which monads you needed, but `with` macro is built-in, and it's a monadic bind for Option types (well, more or less). Adapting it for other monads shouldn't be hard.
For reference (for the "parse transform" approach in Erlang): https://github.com/rabbitmq/erlando - it doesn't look maintained, but it's probably still usable; otherwise, you might get some inspiration from the code :) This also (ab)uses list comprehension syntax:
Red/Rebol has a different, powerful approach to homoiconicity and DSLs.
And there is this XL language that has very interesting approach to extending the language, but sadly the compiler is not in a runnable state, I could only assess it by the docs.
Different designs for different preferences. HHKB is quite classic, it’s been around since the 90s and is just refining and refining the original design.
I can’t go back to staggered or flat keyboards since switching to Kinesis Advantage 10 years ago. These days I’m rocking a Glove80 since the Advantage360 Bluetooth version is so buggy.
Still I wish there were options in my preferred form factor that are as nicely built as the HHKB. So I like to appreciate the aesthetics and craft even if I’d never use it personally.
> That girl is probably at home, grieving deeply for the loss of her father, while at the same time, people are on WhatsApp or in their units, discussing their 'call schedules.' Isn’t that heartbreaking?
No, its not? People did a great effort of ignoring mortality and then get surprised by the most real thing of everything we know. Death happens and you can use it as a powerful tool to get wiser and realise the life is for the living, your grief and your sadness is only for you. In my eyes you are just losing time doing that instead of being happy and joyful.
Hi, this looks great but I tried to do the setup as described in the readme using OBS and streaming to your server and I saw 3-4 seconds delay, how exactly can I reach sub-second?
