Cool that you went and did this! I built @technomancy’s atreus a while back, but don’t actually use it. I should, though…
Thanks - that’s a very cool looking keyboard!
Why don’t you use it?
The reason I don’t use it is simply because I don’t want to become dependent on it. @technomancy travels everywhere with his, and sets it up on top of his laptop keyboard. I could try that, I suppose, but it seems like a habit that’d be very hard to get into. Above all, I don’t have pain from regular laptop keyboards, so the increased ergonomics haven’t pushed me into it by necessity.
But, now that I’m saying this, I really should give it more of a chance, and try it again… There’s no reason not to, for sure.
I don’t think learning a new keyboard will prevent you from using your laptop keyboard.
I switch freely between a maltron 3d and a thinkpad keyboard. The biggest challenge is learning the new keyboard in the first place (about 2 months for the maltron)
You’re right, it doesn’t stop me from using a different keyboard. I spend enough time away from my desk, though, that I feel I’d have to bring it with to ever get comfortable with it.
compsci would be appropriate. If there’s a significant number of people reading about compsci who don’t want to read about plt or vice-versa, speak now or forever hold your whitepapers.
I’d like to see compsci used for something that is theoretically focused but used in conjunction with a “modifier”, like ai, or networking, or plt, or algorithms. But maybe I just think of tags differently than others…
I, too, would love me a plt tag. It would nicely complement formalmethods.
What this tells me is I need to find and post more compsci articles that aren’t also about plt.
(I’m a computer scientist by day)
I’d love a specific PLT tag.
For clarity, do you mean reply to this post to say ‘yes please’ (in which case:
‘yes please’), or do you mean reply and/or upvote the OP?
There have been a couple people people asking for this - if you see this, could you expand on why you want a tag that’s specifically separate from compsci?
Here are some highly-rated Lobsters posts about compsci but not plt:
Here are some highly rated posts where plt may be a good fit:
The way I see it, practices, programming, and compsci are very broad catch-alls for cases where we don’t have enough density to make a dedicated subtopic. python, networking, and ai are all subtopics of programming. compilers and formalmethods are subtopics of compsci. I think there’s probably more people interested in PLT than Formal Methods here, so plt would be a useful subtopic.
I’ve added a plt tag with the description “Programming language theory, types, design”.
Pretty unpleasant results - often-inconsistent behavior makes it hard to even define “performance after warmup”, and lots of measurements end up finding that the “steady state” is either unsteady or worse than the startup behavior.
Nice, and quite thorough, work!
This seems really long for a conference paper. Is it a longer version?
The Appendix was not included in the published version, but instead supplied in the supplementary material archive.
In an attempt to preserve a community which has been a large part of our lives for a better part of the last few years, @angersock @pushcx @355e3b @alynpost and a few other of the IRC folks feel that we can take over running the website. @alynpost will be able to provide the hosting in Santa Clara, CA under pgrmr’s infrastructure. @pushcx will assume the role of head administrator and take over the domain name along with the Twitter account. @355e3b and @aleph- will take over the care and feeding of the Rails codebase.
We will not be making any moderation changes at this time—continuity is the important thing.
Our transition plan is as follows:
This is solely to ensure continued hosting and maintenance of the website, and a continuation of the community. Long-term, if the existing moderators wish to step down, @pushcx will be responsible for picking new candidates.
We would also like to thank you for all of your years of work put into this.
― #lobsters IRC regulars (aka the clawlateral committee)
And I assume @tedu will be in charge of the TLS certificates?
This comment made me super happy :D - Thanks!
That sounds like a great plan, thanks for putting that together. I’ll feel better knowing the site will be managed by a group instead of falling all on one person.
Glad to see your approval. :)
/u/pushcx should be the central point of contact for the migration deets. We’ll keep the community updated!
Great! We’re really happy to step up and take good care of a community we love.
And, for the community: the first update is that I just started an email discussion with me, jcs, and alynpost to handle the technical details of the migration. I’ve migrated barnacl.es a few times, so I’m familiar with the procedure. My guess for a timeline is two weeks, but that’ll be adjusted if needed. I’ll post a comment in this thread when we’ve picked a date or there’s otherwise news.
This sounds great. I’m thrilled to see people working together on this. :)
I got back from talking to the people planning out the transition (aleph, push, socky, goodger, alyn, 355, irenes) on Mumble and IRC - they’ve all been wonderful people putting in their best to ensure the community will experience a smooth transition and avoid any turmoil.
Awesome, glad to have regulars and good people taking things over.
I would strongly recommend, and as a lobste.rs regular personally request that as a group you take a bit of time to define some basic agreement about decision making and ownership, so that it is clear between you all, and also to the community.
This is not a problem when there’s one guy in charge - it’s simple and clear and whether you agree with them or not you have consistency and stability (thanks @jcs !)
When there’s more than one, you need extremely strong value alignment and high levels of trust. If you guys have not known each other for 5+ years and can meet in the same bar to share a beer, you need to talk about and get down some basics. Who makes decisions, how, when; who is in control of the domain / hosting / features / community management.
Personally, I like the ‘benevolent dictator’ situation. It reduces ambiguity and facilitates short sharp clear decisions. Greater than 2 people needs work to define that recognises that you will eventually have a conflict, that some of you will come and go, and that there is no way you can all have perfect understanding of what each other wants for this community and what your values are.
Not doing this is a valid choice too; equal to commitment to cede to whoever has ‘root’ and control of the hosting and then domains if a conflict happens, and requiring proactively thinking about forking / commuity splits.
The way that I personally view it is, @pushcx will step into @jcs’s role and take over as the benevolent dictator.
Is that what you’re thinking too @pushcx ?
That’s the current plan I’m executing on, yes. I want to continue this excellent community. Lobsters is in a good place: we have a healthy, active userbase, the code is stable, bug-free, and has little need for new features, and I’m on sabbatical so I have plenty of time and attention to devote to a smooth transition.
After the migration is complete I think it’s worth having a new meta thread about if we want to shift to a new community governance model. I’m comfortable being BD for years if not indefinitely, but there’s enough folks talking about community models that I want to have a dedicated discussion to explore examples and consider the option.
One of the guiding principles we talked about a lot during the clawlateral committee meeting was that we wanted to stray as little as possible from the existing governance structure for the time being–the site has done well in its current incarnation, and @pushcx is we believe a good steward to carry on the precedent set by @jcs.
The plan explicitly has redundancy in roles (think failover) for all important things you mentioned. We also tried to follow a principle of least-trust and a little bit of separation of powers for the failover folks, so that continuity of service is easy but forking and hijacking is hard.
[Comment removed by author]
So what moderation changes will you make later?
So what moderation changes will you make later?
The first rule of intelligent tinkering is to keep all the pieces. When we say we will not be making any moderation changes at this time, we mean that we have no moderation changes to make. This group volunteered to operate lobste.rs because we like the way the website has been run. We will moderate with the same principles the site has always operated on. The moderation log is available for public inspection. Changes to the site, just like the one announced here, will be discussed in their own meta thread.
Thank you all. I work a lot, don’t know Rails, and don’t really have anything constructive to contribute, but this is far and away the best signal to noise community I’m involved with and I really appreciate it.
If throwing money at the problem will help the new maintainers along please consider setting something up and I’ll chip in.
They said they should be able to pay for everything out of pocket, as far as I know.
Does this mean we can finally get an @angersock plushie?
You guys were my first thought when I saw this post lol. Thanks for your continued commitment to the community ~
Thanks @angersock, @pushcx, @355e3b, @alynpost!
I’d hate to see lobsters die!
I love how fast this plan was put together and I feel it will be in good hands. I was scared seeing this post and am excited to see the community I love will keep going and be in good hands!
Man, I would not want to admin a service where walking the dependency graph was in danger of exhausting stack.
Well - that is a point. I’d expect that the number of services required to exhaust the stack would be pretty high, much higher than what you’d see on a normal system. Maybe reducing stack usage is an unnecessary concern, in this case. However, it’s always bothered me that the precise amount of stack available is something of a magic number, and that we rely so heavily on not exceeding that number even without knowing what it is, how much particular functions use, and in particular without having a reliable way to cleanly back out when we do overflow the stack.
(the post was intended largely as an illustration of general principle - that of playing it safe, and not assuming resources will be available - rather than as an a solution to a problem that was actually being observed. This extends to many other things, but it’s hard to cover them in a concise blog post, and it’s hard to find time to write a lengthier blog post, unfortunately…)
The author of https://bearssl.org/ did something super interesting. He implemented parts his code in a forth variant, but also coded a static checker to guarantee the maximum stack depth so he can allocate his coroutine stacks in a fixed size buffer with assurance it will not go out of bounds and without dynamic allocation.
Super awesome stuff.
Knowing how to avoid recursion, and converting to an explicit stack is definitely a useful skill. No argument.
In this scenario, I might also simply consider a depth counter. Adding a limit is simpler, and one could argue should be the default for any recursive function. It’s still a guessing game to right size the limit, but one can usually make some assumptions, multiply by the fudge factor, and still come out with something that avoid catastrophic failure.
Kind of a side note: some languages include an independent recursion depth counter which would be exceeded before the real stack is exhausted. For example, Python raises a catchable RunTimeError, allowing you do potentially recover. Not sure if C++ has such a feature.
(No, I’m not advocating you should write an init system in Python :P )
Not sure if C++ has such a feature.
Not sure if C++ has such a feature.
Nothing built-in. You could probably wrap a depth counter in a class which auto-incremented in the copy constructor, and pass it as a parameter to each function (but of course the function signature has to change accordingly).
I wonder why they made this an entirely new app, and not just a feature of regular firefox for android…
I suspect, better user model (in UX terms). People would treat it as a new kind of thing instead of another complication to an already complicated app (all browsers are complicated).
It’s at least a different user model. I’ve been using it alongside Firefox and it’s better for me for some things, worse for others. In some ways it’s too minimalist for me: you can have exactly one window open (no tabs), and it’s always an incognito window. That’s great for some things, but for example I don’t use it for lobste.rs, because I don’t want to re-log in every time I visit here. I like it as a default search app though.
Looks like “do I want to log in for that” is the one definitive question to ask yourself when choosing “full browser” over “temporary browser” every time. I just wish there’d be a better way to not have to choose it in Android every time :-)
For me it will be “Do I want to log in/add it to my list of tabs to read later?”
After using it for a bit,
Open with… is a great idea to get URLs into your real browser.
I think zero history might get a bit annoying, you won’t be able to find, “What was that movie I was looking up the other day? Oh rats, it was in Firefox focus”.
Yeah, maybe. I’ll give it a shot anyways.
I use both FF and Focus on iOS, and Focus just fits my model better. Open a site, browse, close or - alternatively - open it in the “real” Firefox for more heavyweight stuff. It’s really nice for people that never close their tabs anyways. :)
I’m using Focus as the default browser so it opens up links from external apps (since it’s fast and private), then regular Firefox for heavier duty browsing and stuff I actually want synced into my history.
Can you imagine taking that on the train? Really?
vmm can boot ISO images now! Great!
(and, as others have pointed out, running docker inside a Linux VM is kinda cheating :P )
Storing my key on the phone… Isn’t that exactly what we don’t want?
I wouldn’t trust my phone to store secrets. LG patch it only about twice a year. Even Google only patch their phones once a month. And we have not even started talking about intentional backdoors… So for the same reason I don’t (any more) store GPG keys on my phone, I will not store SSH keys on my phone.
I was wondering, how does the SSH client talk to the phone?
Your phone (at least for iOS) actually has pretty good secret storage. There was a great talk at BlackHat a few years ago about what Apple does: https://www.youtube.com/watch?v=BLGFriOKz6U
Yes, also some Android devices have it too (TEE/SE). The thing is that, if the device has none of these, any app with enough privileges could read your keys… just like on your computer.
I wouldn’t claim my computer to be saver (okay, okay, I actually would) but this “second factor, put all the trust into a corporate controlled, highly connected, often stolen mobile device” doesn’t make anything better.
Long story short : Use a Smartcard!
Smartcard++ It offers the convenience of having the keys on the device, while not having the keys on the device (at least on android - I haven’t found a way to do smartcards on iOS)!
Could you provide a link?
OpenKeychain is what I am using along with k-9 mail and Password Store, the auth api is still wip. I should have specified that I am not doing ssh stuff yet, sorry if I got your hopes up! :D
Ah this is the same setup as mine, but I’m using a yubikey neo (with nfc) to read the keys
I also did not know about this!
OpenBSD port posted on ports@. Please test!
Neat. Now, who to follow?
All aboard the follow train - https://mastodon.social/@mulander
Followed. I just set up https://mastadon.social/@munyari
I wondered why this link wasn’t working for me until I saw “mastadon” should be “mastodon” :P
I, too, am on this network, at https://icosahedron.website/@mjn
Something that I think would fit the federated model well, if @jcs wanted to do it (or let someone else do it with the domain), is if there were a lobste.rs server. In addition to being able to follow individual people who use any federated server, the client also supports viewing a global firehose (all federated servers) or a local firehose (just this server). The latter, on smallish servers, can provide a kind of IRC-like community, while also interoperating with the broader Twitter-like usage.
I think people are still working out what the social configuration of a federated system would look like, though. Some tech exists, but a lot is still up in the air.
I’m https://mastodon.social/@stevelord if anyone wants to follow me. Mostly posting AVR development and security stuff.
I’m there at @NinetyNine.
I’m there at pnathan.
My Twitter tends to be a blend of liberal retweets, bad jokes, and occasional tech remarks.
I also have some kind of other gnu social account I forgot somewhere, but it wasn’t interesting enough there…
I’m there, https://mastodon.social/@balrogboogie
There is also noteslate priced at ~$200.
Also looks nice, although I wonder what PDF would be like on such a small screen.
Really shitty, like on every small screen. I solved problem of reading PDF by buying an older iPad 3. Not only that the display is bigger, but interactivity and quick reaction of display helps a lot.
So I’ve never gotten into the whole tablet thing; my phone does everything I would want a tablet for (gaming, movies, etc; for any serious work I need a laptop with a keyboard at minimum anyway, since “work” is “writing code”).
This is what I would use a tablet for: taking notes, reading technical documentation in PDF form, etc. The problem is the price. The 40% off price for preorders is nice, but even at $429, I just can’t justify it.
That’s just me though, and I’m known as the…frugal would be the nice word…person of my circle of family and friends.
I don’t think it’s just you. I love this idea in a lot of ways. It’s just that…look, I buy nice notebooks, okay? But this is still many years' worth at this price, and it’s not even guaranteed to ship; it could just be a $430 hole in the floor. And I might even be okay with those two things, except I can’t touch the damn thing, so I have no idea what the build quality or feel is—incredibly important details when we’re talking about something that’d replace my actual paper.
So, do I love this idea? Absolutely. Would I spend $430 on it? Probably not–but definitely not at the current stage of the game.
Completely agree. I read and annotate a lot of papers (which I currently print on real paper). This device looks ideal as a replacement, but it would need to be about a third the discount price for me to seriously consider buying one. Shame.
Its true that rust needs to be easier to learn. I found it quite hard to learn (still learning), and Ive also seen other experienced programmers have a hard time with rust.
I hope it suceeds though. I’d be happy to leave buffer overruns and dangling pointers behind. I do wonder though, if go will win this race, as it’s mich easier to learn and for many, GC is just fine.
Yes, GC is fine for many people. They can continue to use GC’d languages. The (imo) biggest advancement in the state of the art with Rust is that it brings the safety that users of GC languages have enjoyed for years to a space that’s never had that safety before. Obviously, Rust is the not the first languages to try and bring that safety, but it is (again, imo) the most successful.
GC isn’t about safety, It’s about convenience: you could in theory leak all memory you’ve ever allocated until your process halts, and that won’t violate any basic language abstractions, but of course that’s utterly unhelpful behavior. OTOH, ownership is about safety: using a file that has already been closed is wrong, and a high-level language ought to prevent it.
So there doesn’t have to be a distinction between “GC’d languages” and “languages with ownership”: a language can be both convenient and safe! I’d absolutely love a language where strings, lists, trees, etc. are GC’d (as usual); and files, sockets, etc. are deterministically closed (as in Rust).
I think it’s deeply misguided to view these two languages as being in any kind of competition with each other. Go’s primary use-case is highly threaded network servers where a thick green thread runtime and low-latency GC is ideal. Rust’s primary use-case is bare-metal programming where any kind of runtime or GC would get in the way/be nearly impossible to use.
It’s like wondering whether your chisel will “win the race” against your plane. Different tools for different tasks.
Sorry. I didnt mean to imply direct competition as such. What I meant was, these two languages are often bagged together as the “new systems languages”.
I’d speculate that, in the broad realm of ‘modern systems programming’, for many tasks it doesnt matter if the language is bare metal or not, or uses gc or not. In those cases I’d expect ease of use to prevail.
Of course some domains, like perhaps device drivers, would be better suited to a bare metal language like rust.
Would you agree?
EDIT: And yes. Horses for courses. Absolutely.
See also: deoplete.
There’s a why section at README.md explaining some differences between deoplete and this plugin.
There’s an interesting trend in alternative Python implementations where they just sort of peter out, and this one is no different. How does PyPy keep interest?
PyPy keeps interest by… being interesting. I am not kidding, I really think that’s what it is.
PyPy does have the advantage of not really being Python so much as RPython + an implementation of Python. I guess that helps.
I’m actually thinking that Go has something to do with it. Is Go the new Python? The fact that YouTube wrote a Python -> Go compiler, and that Dropbox seems to be giving up and adopting Go seems strongly in favor of this argument.
PyPy’s meta-tracing approach is indeed interesting. And the blog posts explaining how it all works keep people coming back. They also achieve much better than a 2x speedup.
Dropping support for the CPython C API might have helped. It seems that most of the work of pyston went to maintaining compatibility there and the API surface is huge.
Good stuff patrick!
I admit to not being a much of an ESR fan, but this actually seems like a fairly reasonable post.
I gave rust a try a while ago (shortly after 1.0 shipped, as I recall), and at the time, I didn’t find it a very pleasant fit for the kinds of things I wanted to do (network services (http, tcp, udp)). Maybe I just didn’t “get it” or “didn’t give it enough time”. Not sure.
I currently use Go (or python for the occasional rest api), and find it “pretty ok”.
Makes me wonder what languages I will be using over the course of the next 5 years though.
Server-side Swift? Will D finally break out? Crystal? Elixir? Nim? Pony? Myrddin?
I’m seeing a TON of activity in Elixir. Its Ruby-like syntax and real erlang derived MP model seem like a really solid value prop with a relatively shallow learning curve.
The question is what systems programming language will we be using. There’s a ton of comfortable high level languages, but by contrast there are only a handful of systems programming languages. It’s 2017, and I think people are growing tired of buffer overflows, and are super keen to wave manual memory management goodbye. But then GC doesn’t suit systems programming either. This is the “niche” rust is trying to address, but we have yet to see if the learning curve will be its demise.
I’m looking forward to a time when the phrase “systems programming” doesn’t implicitly throw out the idea of a garbage collector. I’d personally like it if Go was a little bit more strict about stuff like checking for err, but if someone said “Hey, we’re going to write an operating system top to bottom in Go” I’d be all for it. Whatever inflection point we needed between user expectations and hardware limitations that called for no garbage collection we went past a long time ago.
I could have maybe entertained the idea that my phone would need it, but my phone has such horsepower now that manually managing object lifecycles is a much smaller issue than just straight up business logic bugs.
Maybe the network stack for a real time online video game. But if we’re doing that, we don’t need a brand-new language to do it; safety isn’t the concern there.
Are you sure about that? I don’t doubt what you’re saying, but I’m hearing and seeing an awful lot of movement around go even in contexts that would have been previously considered to be “systems programming”.
I agree there will always be a niche for non gc languages that need max to the metal performance, but how big that niche is has yet to be determined IMO.
As to Rust, I think most people agree there’s an enormous amount of untapped potential there. It’s unfortunate that some large company with associated large $$ and man hours doesn’t back the project. I think that would help smooth some of the rough edges and make the adoption experience a bit smoother.
Elixir has a shallow learning curve. OTP (the main benefit of BEAM languages) doesn’t, especially for web developers used to Ruby and Node. It’s not “hard” or impossible, but like Rust, it’s not Python.
Good point about the OTP aspects.
I’d be interested to learn what the performance characteristics of non OTP Elixir are versus similar code running in Ruby or Python.
Anecdotally, I’d say Elixir feels about 2-3x faster than Ruby or Python in the single-threaded case. But just about any Elixir app will use multiple processes (Erlang processes, not OS processes), and at that point the benefits of concurrency quickly leave Ruby and Python in the dust.
EDIT: A couple of benchmarks say roughly the same thing I do:
I think raw Elixir is faster, but the problem is that every real world library or use case of Elixir will use OTP in some way or another (at the very least, a GenServer, which is admittedly very easy to learn).