I still find a decent amount of the integration, like KIO, is still there and works well - it puts MacOS and Windows to shame in terms of how I can just interact with files anywhere as if they're native within KDE apps.
It's kind of a shame that Konqueror fell to the wayside, but modern browsers are so complicated I cannot fault them for focusing elsewhere.
This is where I separate "manager" from "leader". As a principal level IC, I'm part of "engineering leadership" along with the senior managers, but not a manager.
The work isn't that different to management, sure, but it is different. You're not doing performance reviews... but if someone is over performing you can help get them promoted and if you think someone is doing really badly you can help get them fired.
Unfortunately, at their stated range of 160nm, you're looking at only getting as far as Big Sur before the entire craft needs a recharge - it's much more aimed at island and port hopping, I suspect, than long distance travel.
Still, I am excited to see ground-effect vehicles/ekranoplans back in vogue!
Author here - it's just to reduce support surface area. I know I'll need PostgreSQL's full text indexing and GIN indexes for hashtags/search eventually, and I probably also want to use some of the upsert and other specialised queries, and it's easier to just target one DB I know is very capable.
For reference, when I say "small to medium", in my head that means "up to about 1,000 people right now".
I'm (worriedly) curious how this will affect people trying to change jobs on a H1-B, as technically you need to file a new petition each time, and I can see them somehow denying those too.
I've replied to the post on the forum, but if this is the default way Jupyter runs then we're going to have to figure something out longer-term. Calling the Django ORM from an async thread just isn't safe...
I'd love to hear your suggestions for changes we could make while keeping it somewhat WSGI-compatible. It took a few years to refine it to where it is now, so it's not like we just threw something at the wall.
It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.
I would agree with some of the points - speed (which is stretched over two points), concurrency, and the ability not to do magic as easily, but several of the points (compile time, available developers, strong ecosystem) are not a "versus Python" at all but rather against other languages.
Personally, I see a language like Go and Python as solving different spaces. I wouldn't write a lot of website business logic in Go, and I wouldn't write a low-level TCP redirection daemon in Python.
I can't say much on the subject, at least not without official approval, but understand that the original Lanyrd team have not forgotten about the site; asking us to fix it isn't really giving us any new information (sadly).
If you want to make requests of any kind you're better off reaching out to Eventbrite directly.
There is, actually - the US has a (slightly worse) government data repository, but there's several LIDAR sets of the Bay Area, mostly from coastal surveys.
I'm the main person in Django working on 2), and this is interesting for sure, though our current code is based on Twisted since we need python 2 compatability (there's some asyncio code, but not a complete webserver yet)
We're not bringing in the whole of Django REST Framework, just some of the underlying mechanics that are useful for all apps (like content negotiation). DRF will remain a third-party project.
As for Python versions, there isn't any plan to drop 2.7 yet and Channels will work on it. It might be we move to Python 3 only at some point in the future, but there are no firm plans right now.
I agree a little bit, but also part of building out a framework is making choices for people - waiting, looking at the problem space, and picking a solution that most people will be happy with.
There are some projects that Django is not the right solution for and something like Flask/Werkzeug is definitely better, for sure, but I'm hopeful that the work being done here will help out the majority of people; it brings a lot more than just WebSocket support to the table, that's just the headline feature most people run with.
Yeah, it's a fantastic step and we're very happy they piloted the program. The Django Software Foundation has also hired a part-time fundraiser to try and make the project self-sustaining; we're trying to make the project sustainable as a whole and not just a timesink for those who are lucky enough to have unpaid spare time.
The DLR article says that, if the solar panels work, it'll last a lot longer - until it gets too close to the sun and the heat gets too great (about 2AU):
It's kind of a shame that Konqueror fell to the wayside, but modern browsers are so complicated I cannot fault them for focusing elsewhere.