Probably because they want cameras they know will work and survive in a deep-space environment. Space is hard. Once you get out of the atmosphere and magnetosphere, it's an unkind environment for electronics. They're probably going to spend the money, effort, and mass on some nice cameras for manned missions, but these are little cameras that mount to the ends of the solar arrays.
It is also probably a data rate issue. They will have higher priority data coming back from the spacecraft, especially for a first iteration, and in the early stages of the mission.
It is quite possible that once things have stabilised that the video and pictures being sent back will improve. For the ispace lander we take much lower resolution images throughout the mission until we have landed and have the high gain antenna in a stable connection.
> while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
It's designed first and foremost to be a language to help compilers turn large matrix math operations into automagically vectorized and parallelized operations. If Rust is the language for close-to-metal memory-safe systems programming instead of C, modern (F90 and later) Fortran is the language for close-to-metal high-performance computational programming instead of C.
Thinking about it, I'd say the comparison to Rust for mastery of its particular domain is actually quite apt.
Rust is actually the first serious contender in this domain, given that it has native support for parallel, concurrent and distributed programming and also deals elegantly with the aliasing issue that hampers optimization in C/C++. It's nice to see that LLVM is getting an official Fortran frontend, it will ease interop (including with Rust) and make it easier to compare code generation across projects and languages.
It's been my understanding that Fortran is loved by physicists due to it's procedural approach, and doesn't require learning objects and inheritance, etc.
There's a lot to learn in higher level physics, so having the simplest language, without tons of features to fiddle with, while also being very, very performant is preferable.
I have a feeling that much of this work end end up in Julia however.
No. Fortran is loved by physicist because it has an excellent 'impedance match' for the problems they are trying to solve. It has a multi-decade track record of expressing physics problems so it's the computer lingua franca there. And it has an extensive, high-quality and (perhaps most of all) tested ecosystem they can work in. It's not rocket science (unless, of course, it is); right tool for the job and all that.
FWIW...Fortran has had explicit OOP features since at least the 2003 standard (e.g. "type extends"). You aren't "required" to learn those features to use Fortran, but that's true of any number of ostensibly OOP languages.
Lastly...endless people (virtually always non-physicists who wrote a couple of lines of Fortran-77 in college) are continuously popping into the conversation with "well of course dump musty old Fortran for the NewHotness language because ew Fortran". Hasn't happened yet, and the Fortran folks have evolved from -77 to -90, -95, -2003, -2008 and lately -2018, so why would it?
I think that at least part of it is APL's dependence on specialized hardware (at least back when I last encountered it in the 80s). At the Claremont Colleges, most computing access was on VAXes running VMS, although there was a single Unix machine at Harvey Mudd and Pomona College had an IBM minicomputer with 3270 terminals (plus a couple of the IBM graphic terminals) and it was Pomona's system that was the only one that had APL because the 3270s could use the specialized character set while Mudd (the science/engineering school) did not. The big language push at Mudd back then was towards APL, perhaps because a lot of aerospace companies sponsored clinic projects (all engineering students and some other majors did a sponsored real-world project in their senior year).
I remember writing some data analysis code in Fortran for my freshman physics lab and the TA was surprised to see my choice of language.
Rust and Go both aim to create safe, performant, modern languages suitable for use from the systems layer up, differing in some of their primary goals:
Rust is a sane C++: Zero-overhead abstractions, not afraid of language complexity.
Go is a modern C: Simplicity, stability.
They have some overlap in what they're best at, but they both take on unique and important missions that both need to be targeted, in our rapidly expanding universe of software engineering.
At this point it’s history: Go and Rust both got started around the same time - one by Mozilla and the other by Google. They’ve both reached critical-mass over the past ~10 years - so expecting one of them to disappear is like expecting Autodesk to choose between 3ds and Maya...
> The last-modified headers indicate that the front page and docs have not been updated since May 2018. This is not a viable platform and the analysis of Twitter's technical shortcomings is facile. The original 140 character limit, now doubled to 280 characters, was originally constrained by the SMS interface Twitter supported but ultimately imposes a preferred content style that distinguishes the microblogging experience.
Your analysis of Blerg's analysis of Twitter's technical shortcomings is facile. It's a system that the author put together while intoxicated to poke fun at Twitter. Reading any more into it than that is at best highly unadvised.
> It's a system that the author put together while intoxicated to poke fun at Twitter.
The HN title is "a microblogging platform", the landing page has a section titled "But what's wrong with Twitter?", and the documentation has a "Design" [1] section. If the author intended to poke fun at Twitter as a stand-in for all microblogging platforms then leave out the engineering aspects and if the author intended to poke fun at Twitter engineering then land some technical blows. If the point of the exercise is to demonstrate how much code and documentation can be pumped out during a drinking binge then the author should state that upfront; that context is useful.
Despite my ex-roommate's well-intentioned defense, I was probably sober for most of it. It was also a decade ago and I'm somewhat wiser now. As mentioned elsewhere, I learned a lot about making such bold claims to the Choir of Ultimate Pedants. But it was something I had fun with, and I think the world needs more of that. :)
When I see someone writing a database from scratch I search for the rationale and the core problem being addressed. The HN title is misleading and needs a date context which is obviously not your fault but comments attempting to provide the missing context should not be dismissed as pedantry either.
If the context of a fun learning experiment was made clear on the landing-page and/or documentation then this thread could have been about architecture and programming which I think was what you wanted originally. I suspect the broken git repository didn't help matters. Overall a missed opportunity.
> It's very common to think about computer security primarily in terms of fixing vulnerabilities. In reality, security teams spend a lot of their time on a different goal: making bugs hard to exploit. This often takes the form of lowering privileges and introducing exploit mitigations. Windows 10 has a lot of investment in those areas, whereas Windows 7 doesn't contain any of the improvements made in the last several years. That's why even though Windows 7 continues to receive security bug fixes from Microsoft, it is considerably less safe to use.
SpiderOak | REMOTE | Full-Time | PhoneGap-Centric Mobile Engineer
SpiderOak builds and provides Zero Knowledge cloud storage and collaboration solutions, with our Semaphor team collaboration service, ONE backup, and Encryptr password management. We're a growing team of some ~40 people spread across the world.
Javascript App Developer
The front-end to our latest project, Semaphor, is built in HTML5 technologies using Electron on the desktop and PhoneGap on mobile. We need more hands to help bring out new and exciting features to market. If you're interested in joining a small but growing group of amazing developers building amazing secure collaboration software, this job is for you! Experience with iOS and Android dev is strongly preferred.
