I wouldn't go as far as telling something is badly written just because it's written to work on one platform. It can be an exceptional application even when it only works using a single platforms' intrinsics. Similarly a badly written application may work on many platforms
Specifically for Video encoding I'd look into benchmarks about what certain ARM architectures can do. Not all encoders can correctly utilize them and they may end up very slow.
>versus the AWS shop where the Dynamo guy knew the innards of the database by chapter and verse)
Definitely has a big impact on it. The angle at which people approach these databases is completely different from my experience. MongoDB is advertised with words like "developer friendly" and "just works", so people tend to just start it up and not read too much into it.
On the other hand DynamoDB was described to us as "monkey's paw", "Carefully read before use", "know what you're doing". And so we combed through first all the pitfall blogs, then AWS documentation, and then carefully tried out all the features we wanted to use and tested the scenarios separately.
How does he know how a black box database works inside and out?
That's an issue with dynamo. Sure you can memorize the API, but you have no idea what is actually going on and aws support will NEVER tell you what is happening.
Postgres, Cassandra, etc are source available and yes I have multiple times looked at Cassandra code to figure out what it was doing.
DBs in general have a lot of unavoidable complexity swept under the rug. Like, I don't think most people realize Postgres and MySQL don't do full ACID transactions by default. But it's even worse how special DBs made for huge shardable data like Mongo market themselves as beginner-friendly.
Also the SQL timestamp vs timestamptz thing is just silly and avoidable. I want to know who I complain to for that.
I wonder how that would fare in our climate in finland, where the ground freezes and thaws all the time, breaking just about everything we lay in it, including roads, signs, pipes, foundations...
Another issue in Finland is that the average soil temperature (like, a few meters down) is only five or six degrees. But that leave a lot of room for a heating upgrade...
IMHO if you can capture the massive surplus of sunlight in summer and use it in the winter, it would be a major win. Some way to set up a big underground heat reservoir ?
Cloud pricing for bandwidth is really limiting for a lot of applications. For comparison you can get a 1gbit/s line with your server on OVH EU for about $100/mo, which you could utilize for a theoretical ~321TiB/mo total transferred
>A local Internet registry (LIR) is an organization that has been allocated a block of IP addresses by a RIR, and that assigns most parts of this block to its own customers
Doesen't /64 mean that you can't create additional subnets within your ISP given range? I thought /56 was the smallest allocation an ISP could make for a residential allocation.
I think it's great that the smallest subnet size is designed to be as large as to never run out of addresses in any conceivable application, no more wasting precious time manually assigning addresses and thinking about subnet economics
> Doesen't /64 mean that you can't create additional subnets within your ISP given range?
Effectively yes.
> I thought /56 was the smallest allocation an ISP could make for a residential allocation.
They can and often do make /64 allocations. There is an RFC (I think, might just be RIPE guidance or something) that recommends that ISPs issue larger to each customer. Many don't (as it is just a recommendation). Ideally they would allow a customer's router to request a larger allocation like /60 or /56 via a prefix delegation message.
/56 is the smallest they're supposed to allocate for customers, but I've read stories about ISPs providing people with /128s on their CPEs...
A /64 can actually cause problems if you're chaining routers together. In IPv4 that'd give you double NAT which is obviously terrible and not recommended, but in IPv6 that's a fine use case that shouldn't cause any trouble as long as you have the ability to create sufficient subnets. With a /64, you're stuck doing weird stuff with DHCPv6 to get the subnets to work regardless.
You don't need double-NAT with ipv4 to chain routers together, just route between different private-allocation subnets. I was running a setup like that to get ethernet access to a part of the house via wifi. Changed it for ipv6 though because my isp only gives me a /64
They may be misunderstanding how their ISP provides IPv6 address space. For example my Comcast connection assigns a single /128 to the router, then a bunch of /64s to each subnet I have set up.
I've been browsing their site for a few minutes now and I'm still lost on what Fleet actually is.
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
It seems to mostly be a competitor to VS Code, i.e. a relatively lightweight editor with support for distributed operation (where the local part is only a UI, and everything else can run remotely).
The linked product page seems to sum it up pretty well:
>We built Fleet to be a fast and lightweight text editor for when you need to quickly browse and edit your code. It starts up in an instant so you can begin working immediately, and it can easily transform into an IDE, with the IntelliJ code-processing engine running separately from the editor itself.
It's splitting the difference between text editor and IDE. It's their answer to people complaining "IntelliJ takes too long to start up" while keeping the IDE features that you lose just using a text editor.
I think it's more that there are now many large companies that now deploy VSCode as a shared, distributed editor. When I was at Google they were starting to replace their proprietary "Cider" web-based editor (for Google3) with a "CiderV" which was a modified hosted VSCode. A hosted VSCode instance makes a lot of sense for a company like Google where source-code-on-laptops is generally forbidden and developers are often issued Chromebooks etc. It solves & improves the distributed/remote development problem without requiring organizational changes. And it's much faster and smoother than RDP, etc.
So those are potential customers that JetBrains was/is losing. My brain is almost 20-years-wired for JetBrains products. I would have been much happier to be able to use a remote JetBrains IDE vs a remote VSCode.
There are also people for whom the existing JetBrains IDEs will always feel big slow and bloated. They have a lot of features packed in and come with a lot of lifestyle assumptions. I can see the value in JetBrains rolling out something that feels lighter-weight.
Exactly, when you want to download JetBrian fleet, you'll first have to download their "JetBrain Toolbox", which looks and functions VERY similar to the adobe CC menubar app.
To be fair they ship a large number of IDEs and Toolbox makes managing them a lot easier. I mostly only use IDEA Ultimate and CLion but I use the others occasionally too for certain tasks but don't necessarily have them installed all the time. Toolbox is installed on all my machines so I can simply install what I need when I need it, i.e Datagrip to generate some nice diagrams of some random DB I need to look at, etc.
My gut sense from watching this for a while is that Fleet is a hedge by JetBrains against the risk of technical obsolescence for the IJ platform. VSCode introduced some key architectural changes and new UI which may or may not actually be better than their own products, but, if they are better then JB would be left without a good way to respond.
So. They start Fleet. Different to their existing products in several ways:
1. Doesn't use the Swing UI toolkit. Uses a custom home-grown thing on top of Skia. Still JVM based though.
2. Runs heavy computation in a backend with a network protocol between that and the UI.
3. Has a VSCode style UI.
4. Uses JSON files for configuration.
Meanwhile they are also attempting to respond to the threat with IJ itself. So they have been prototyping a new VSCode style UI in IJ, implemented with Swing. I'm using it at the moment and I have to say it's actually quite nice. I was super skeptical at first. No, really skeptical. I liked the classic IJ UI, nice and dense, lots of features. But the new UI has won me over. It's been freshened up, is still just as efficient, looks nicer too. I think the success of that project (at least for users who want it) calls into question a big part of the Fleet value prop. Also they've been adding remote development/backend support into IJ itself, a lot of that is being built around their pair programming Code-with-me thing which is a fairly sophisticated data sync protocol under the hood.
So JetBrains is setting themselves up here for some serious product management pain. The IJ team are rising to the challenge and it's not at all clear that VSCode will retain its competitive advantages beyond price within a year or two. Swing is not turning out to be the millstone around their neck they apparently feared, and the new UI feels modern and fast even though it's based on this old toolkit. Meanwhile the VSCode architecture in many ways doesn't make sense and is clearly the result of asking "how can we build an IDE within the constraints of a web browser" and not "how do we build a great IDE"? The client/server architecture is quite painful in all kinds of ways compared to threads+locks, devs tend to have good enough machines for code indexing and comprehension, and IntelliJ index builds can be outsourced to the cloud anyway. If IJ starts to really nail the Gateway stuff (see the recent Google Cloud Workstation announcement), what does it leave Fleet for? And how would they resolve these two competing products?
If I were running JetBrains I'd be tempted to keep resources assigned to Fleet relatively limited and wait to see if it takes off organically, whilst simultaneously closing the gaps in IJ with VSCode. This does not just mean the features listed so far but also means getting serious about their "lightedit mode" and plugin API. JetBrains have a cultural problem in which they historically have actively resisted anything resembling code documentation, thinking that code should be self-documenting. Their plugin API docs are still poor and incomplete even after many years partly as a consequence, and although the JVM can run many languages, JB only really support Java and Kotlin for plugin dev. VSCode has taken off partly for the same reason NodeJS and Electron did - it lets web devs apply their skills in a new context. Language server took off because it lets obscure language communities use their own language to make IDE plugins instead of needing to use Java. Add Graal to IntelliJ, make JS a first-class plugin language and explore how to do non-network based integration with other languages. It would help them a lot.
