HN user
Do you have any substantiation for either the point that onerous regulations are the primary impediment or that most of these have been created since 2008 (by fiat or otherwise)?
It's always going to be cheaper to make things in places where labor costs and environmental responsibility expectations are low.
There are different solicitation types. Not everything is Lowest Price, Technically Acceptable (LPTA). LPTA is not usually the solicitation types for anything R&D. It's more for "commodities", like tires, or bids against things with very detailed specs, like construction/infrastructure projects.
That said, it's a fair criticism that procurement specs are often poorly written, and the evaluation processes insufficiently rigorous.
Good job penalizing this project lead of an ambitious open source project for his engagement with the community.
Obviously, needless dicklike comments can only help the project and its users.
I was confused by the use of "EDRAM" vs. "eDRAM" here and by the HN capitalization of the original article.
The EDRAM I'm familiar with, by a company called Ramtron and later Enhanced Memory Systems, seems to be largely lost to history. It's discussed in this relatively recent presentation, see slide 16 onward: https://site.ieee.org/pikespeak/files/2020/08/Silcon-Mountai...
Interesting, thanks!
Wow, I'm way out of date - when did Dave Chinner step down as XFS maintainer?
We probably need better, consistent terminology for different types of "not all the freedoms of open source but not proprietary secret source either", the way "open source" means something very specific.
The Wikipedia page you cited opens with "Source-available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open-source."
So by this definition, "source available" is a superset of FOSS, but not specific enough to imply what the user can and can't do with the source code. It makes sense to name classes of license within the "source available" umbrella that spell out what freedoms are restricted/preserved.
The Big Time license is not specific as to whether the covered software is provided in source or binary form, and is easily applied to source code distributions. Probably the reason I associated this license with "source available" is the primary license author is a prominent U.S. lawyer involved with open source and I'm pretty confident it is written to be applicable to source code even if it is not explicit about it. Similarly, the BSD license doesn't require that the license be attached to source code - one could release binary-only software under the BSD license.
First of all, some of them DO call themselves that even though they unambiguously aren't. And even for the ones that don't, they usually try to sound as similar as possible to it and downplay the differences.
There was understandably uproar about things like the "Commons Clause" and similar attempts to retrofit obligations to pay onto open source licenses. I have no disagreement with rejecting these as misrepresentations of open source. But if no such misrepresentation takes place, this line of objection is bogus. I gave an example of one license that does not misrepresent itself in such a way. I'm sure there are others and if not, attempts should perhaps be made to develop others, just as we have multiple open source licenses available.
> Regardless, something needs to be done about the sustainability gap in open source other than writing messages like what's linked.
That feels like the politician's fallacy. We need to do something, and switching to fauxpen source is something, but that doesn't mean we need to switch to fauxpen source.
I regret my phrasing, "something needs to be done," which does indeed sound like a politician. So let me rephrase. There is an axis, with proprietary secret source code and FOSS anchoring the ends. This axis is a good proxy for monetizability, but the axis itself is about freedom. With secret source, no user gets any benefit from the source. Source available, is, to me, a genuinely constructive attempt to address the need for developers to be compensated, while still giving users many of the benefits of access to the source.
I don't think source available is going to be something we "switch to" so much as, if some developers need income from the code they put out there, this is a far more user-centric option than telling everyone to download binaries for platforms they may or may not use and submit themselves to intrusive license checks. If you want to get a job at a RedHat or Collabora or try to have your employer cover your open source time instead, more power to you, source available certainly doesn't stand in the way of that.
It's not just one project that can't. If a given bit of code isn't open source, then NO open source projects can incorporate it.
Open source projects have no hope of incorporating secret source software either. At least with source available, users can look at the code, make changes, build it themselves, and if they fit whatever "gratis" criteria are a part of the license, they don't have to pay either.
They deceive users and leach off of the good name of open source
How do they do that if they don't call themselves open source (or "Open Source (TM)" if you prefer) in the first place?
Regardless, something needs to be done about the sustainability gap in open source other than writing messages like what's linked. The inability of your project to incorporate someone else's code shouldn't consign the rest of us to not have the benefits of access to that someone else's code outside of a proprietary binary.
If you want people to pay then be paid software.
It seems like source available type licenses (e.g., Kyle Mitchell's Big Time license: https://bigtimelicense.com/ ) are a reasonable middle ground for being paid software without giving up many of the benefits of open source.
I'm hoping there's a notable uptick in adoption of licenses like these.
* Brake fluid. It's hypergolic, after all
You probably meant "hygroscopic" here. One probably doesn't want to be carrying hypergols in their car!
It's not a boolean matter of the assumptions being "not valid" - sometimes, the non-idealities are of significant enough magnitude to make a meaningful difference. Other times not.
If one is taught ideal spring-damper theory, they are told friction in the damper is neglected in the mathematical model. If I use this theory to size the spring and hydraulic damper for some application where the forces involved vastly outweigh the damper seal friction, it's likely this non-ideality doesn't impact the answer enough to affect my sizing.
If I'm trying to eke out every last bit of performance from the spring-damper system and minimize damper lag, then the seal friction probably does matter.
Either way, when the theory was taught, it was done by stating what assumptions were used to derive the theory. How much those assumptions affect the validity of the model for a given purpose is an "it depends" matter.
This quote has always seemed cute, and coming from Berra it would be, but hardly true.
Theory (at least in physical disciplines) is always taught with up-front statements of assumptions, what non-idealities are assumed away in order to tractably develop a theory in the first place. It's not taught by theory that theory transcends whatever simplifications were made to arrive at the the theory. Physical theoreticians do not contend that theory has no differences from reality.
First of all, I genuinely wish him well. He's an extremely talented developer, and we need more people focused on securing our digital infrastructure. My sentiments mirror what others here have said, hoping he can work his way through recovery and growth to be in a better place down the road. And if there really has been crazy stuff like swatting, that punishment is dealt to the perpetrators.
However, in his role leading a project that ostensibly wanted people to use it, he had a very offputting set of personality characteristics that worked against that goal. He was very opinionated and often condescending, frequently stating opinion as fact and being shallowly dismissive. I'm not talking about arguing with people asking that he add shiny baubles, but just generally almost annoyed the person he was talking to didn't realize the obviousness of their own stupidity in not seeing it his way.
Then, he had a gigantic victim complex where any comment that could be perceived as negative whatsoever was seen by him as some grave personal slight deliberately intended to hurt him. It wasn't sufficient for him to explain why he thought others were wrong. It was frequently accompanied by accusations of bad faith, of potential coordination with others trying to take him down, etc. It came across as hysteria. Not to mention the needless aggression with the Calyx developers, etc.
A few years ago, the IRC channel had a lot of this victimization and desperation-type content from him. It got to a point I was uncomfortable using GrapheneOS out of concern for the leadership and prospects of support.
It used to be Theo de Raadt of OpenBSD and to some extent Linus were benchmarks for "prickly" open source leaders, but I think Daniel gave them all quite a run for the money.
It's good that despite all that, Daniel managed to find some developers he could get along with and the contributor base grew beyond him. Here's to hoping the new leadership team steadies the ship and manages not to be so hostile to the community.
Edit to add: looking over the [2] link from parent, it's clear he did provide a lot of thoughtful, helpful answers as well, so I wouldn't want to downplay the great deal of good for which he's responsible. We're significantly better off that something like GrapheneOS exists.
Not usually in this habit, but really needed to commend you bringing in not only Robocop, not just stopping with Dick Jones, but including his quote as well. This really made my day.
Signed, A fan of Robocop as dystopic corporatocracy preview
The most horrific thing I discovered about tcl is that curly braces within comments can affect flow control.
This is not true. Once Tcl sees a valid comment, the rest of the line up to the newline is treated as a comment. An odd number of trailing backslashes suppress the newline for interpretation purposes. Within the comment you can use braces or whatever without affecting control flow.
I want to like systemd, especially since it is the default and has all the mindshare in Linux. I'm also not particularly in love with the historic shell scripts approach, as some are. Some systemd elements, such as its journal, are convenient.
My issues with it are:
- If you setup an atypical configuration, particularly involving luks volumes, it is not hard to break systemd and dracut's assumptions, and then you will have a hell of time trying to boot and survive systemd updates.
- When it breaks, figuring out what the hell is going on involves having to learn a lot of systemd, which has lots of its own unique vocabulary and logic. There are many pieces and moving parts. It feels like someone went "microservice-crazy" with the init system and like there has to be a simpler way. The surface area of systemd is enormous.
- The whole anti-split /usr crusade is excessive. You might want to have /usr as a separate volume so you can mount it with the nodev option, for example. Why should that be forbidden?
If you conform to systemd's expectations about system configuration, I'm sure it works fine regardless of its elegance/inelegance and excessive complexity. If you would like to do things differently in ways that Linux's building blocks otherwise permit, you could be in serious trouble.
This isn't "you like vanilla, I like chocolate, to each their own." Grandparent post states a view on the tangible harm caused by this media empire. Using the flavor analogy, it's more like vanilla vs. lead ( https://en.wikipedia.org/wiki/Lead(II)_acetate ). In that framing, it makes sense to hope lead-based choices go away.
If you are willing to go to the professional/office grade, I can recommend the Canon imageClass line (caveat: only the models with native Postscript support) for use in Linux or wherever you might not want binary blob drivers: https://news.ycombinator.com/item?id=29869389
Avoiding their blobs may deny you of advanced features, but for documents where you're not aiming for max photo quality or color matching, it works very well.
Anyone is allowed to prefer a programming style that suits their aesthetics and habits, and like that one over all others. Aesthetic preferences are a very valid way to choose your programming language — ultimately that's how we all pick our favourite languages — and there's no need to make up universal empirical claims to support our preferences.
Thanks for the links though.
There's really no need to assert what is really a conjecture, let alone one that's been examined and has not been verified.
If you believe the conjecture is intrinsically hard to verify, you're conceding that you're only claiming a small effect at best (big effects are typically not hard to verify), and so there's even less justification for continuing to assert it.
This is why I did not make sweeping statements along the lines of "the majority of dynamically-typed software in production [no qualifier on what "production" means] would have fewer bugs if it were statically-typed" or the like.
I am not familiar with the studies you are relying on to make the point that statically-typed languages have no significant difference in terms of number of bugs in production compared to dynamically-typed. Measuring such things is challenging, and the most useful measure may not be in terms of "bugs in production" but by a number of other measures, such as how long it takes to surface bugs after the code is accepted by the interpreter/compiler, how much time is spent on writing the implementation vs. writing & running tests, how many bugs occur on major refactorings, etc. If you have citations for studies you like, I'm certainly interested.
My use of colloquialism aside, it is strictly more rigorous to catch equivalent bugs through the interpreter/compiler than through testing or other runtime-dependent approaches. In my own experience, despite being a more experienced programmer in my Julia-writing phase than in my OCaml-writing phase, it takes much more time to surface bugs in my "running" Julia code than OCaml. The lack of determinism in surfacing these bugs does not suggest as much confidence in the Julia code. You could counter by saying I'm probably able to implement more functionality in Julia per unit of up-front development time than the equivalent development time in OCaml, which I'd probably have to concede, but that just highlights measuring these things in a directly-comparable way is not easy.
In the physical engineering disciplines, we often have disagreements about the level of sophistication of physics-based models that should be used for design and analysis. It's very reminiscent of these static vs. dynamic typing discussions in software development. There isn't a "one size fits all" answer, but generally, the more complex and expensive the system, the more important the models incorporate greater physical fidelity. My analogous conclusion here is a lot of technical/numerical code is complex enough that more rigor enforced by the language would likely be the right tradeoff for a net win on up-front correctness (vs correctness as a result of testing).
I've worked on large engineering projects in physical disciplines. When I am the customer, I often bring in a group of independent experts to review the design products. Often these experts provide inputs that are not 100% usable in the form they're provided. One may have to disentangle their conflation of related-but-not-the-same issues, or ignore the specific solutions they propose, etc.
That being said, I have learned the hard way not to ignore or trivialize these review inputs, even if they are not immediately actionable as-provided. Users and reviewers are really good at figuring out weak areas or flaws even if they can't articulate the solutions, fully unentangle related issues, or do all the generalization or abstraction that would make those issues easier to address. There is usually some truth underlying the negative feedback.
The article looks to potentially be an example of an expert review in the above vein. If you are able to take a step back, you might find the HN discussion on this submission to provide further inputs to help figure out how any of this should be channeled into language, practice, and ecosystem improvements. Certainly there is more to work with here than little "to take away other than that we should work even harder on bugs and quality."
We can trade anecdotes on this topic, but I've written numerical code in OCaml and also Julia. The strictness of OCaml's type system is painful in a numerical context but for virtually all other things it is awesome to pass code into the interpreter/compiler and catch structural problems at compile-time rather than maybe at runtime.
OCaml's type system is almost certainly not the right model for Julia but the ad-hoc typing/interface system Julia currently employs is at strong odds with compile-time correctness. There's almost certainly some middle ground to be discovered which might be unsound in a strict sense but pragmatically constrains code statically so there is high likelihood of having to go out of your way to pull the footgun trigger.
You can see how little type annotations are used in practice in major Julia libraries. It should be integral to best practice in the language to specify some traits/constraints that arguments must satisfy to be semantically valid, but what you often see instead is a (potentially inscrutable) runtime error.
So, I really respect what you've done (for those who don't know, Chris is the original developer and lead of DifferentialEquations.jl) and use your work heavily. However, understanding and writing idiomatic Julia, especially with these large packages, is severely hampered by the documentation culture.
A prior comment I made, all of which seems unaddressed to me three years later: https://news.ycombinator.com/item?id=20589167
To be fair, I've only submitted a small documentation patch for a package and haven't significantly "put my money where my mouth is" on this topic. But I hope the next time there are thoughts among the core team about what is the next capability to add to the language, addressing this deficiency is prioritized.
I agree with the kernel of your point here, but also with the author of the article when he says "But systemic problems like this can rarely be solved from the bottom up, and my sense is that the project leadership does not agree that there is a serious correctness problem. They accept the existence of individual isolated issues, but not the pattern that those issues imply."
My impression is that the Julia core devs are more focused on functionality and being able to construct new, more powerful, faster capabilities than on reflecting on how the foundations could or should be made more rigorous. For this, I think the devs have to philosophically agree that soundness in the large should be a first-tier guiding principle, and that the language should have mechanisms whereby correctness-by-construction can be encouraged, if not enforced. Presently, notions of soundness seems to only be considered in the small, such as the behavior of specific floating point ops. Basically, I don't think the core devs are as concerned with soundness, rigor, and consistency as they are with being able to build more impressive capabilities.
I don't want this to sound like I'm ungrateful for the awesomeness that Julia and its ecosystem does bring to the table. For numerical computing, I don't see any alternatives whose tradeoffs are more favorable. But it is disappointing that it doesn't seem to learn the lessons about rigorous language design and the language-level implications for engineering vs. craftsmanship appropriate for a twenty-first century language.
I'm an engineer in physical disciplines, and I don't think it's a certification issue. It's more that "engineering" in the software world is conflated with craftsmanship. The word "engineering" as used in relation to software is basically interchangeable with "technical work". Let me hasten to add, this is not intended to be pejorative or haughty, rather an observation.
Whether it's bridges, aircraft, or other complex engineered systems outside of software, there is a fundamental commitment to correctness, as assessed against physical principles such as conservation laws and both high-level and low-level verification criteria. Some software orgs (I think mostly in safety-critical systems) apply this kind of rigor, but most software development does not. Just look at the pushback on this site for development systems that increase rigor at the expense of "development velocity", such as memory-safe languages, powerful type systems, formal methods, etc. No civil engineer is going to be OK "shipping" their product without stress analyses, material property knockdowns, and the like.
My suspicion is that the root of this lies in an inability to systematically reason about software the same way we can about physical systems today. The tools and principles for correct-by-construction software are more primitive and harder to use than their equivalents in the physical realm. Also, lack of rigor in software still gets you a lot of powerful software and society seems remarkably tolerant of shitty software outcomes.
All software doesn't need to be engineered, the same way no one engineers a hand-crafted piece of furniture. But our software infrastructure ought to be, and it surely is not today. It will be awesome when software engineering starts living up to its billing, as I hope it one day does.
The single best antidote I have personally found against loneliness is staying busy doing things I really care about. If you would prefer something outside of work/career/projects, there's almost certainly some kind of self-improvement To-Do list you've built-up. Why not start tackling it with gusto?
I'm surprised to see so few recommendations for Arkenfox's user.js: https://github.com/arkenfox/user.js
It's a pain to go through all of it the first time, less so with subsequent updates, but it's extremely comprehensive for most Firefox issues.
Then, I run uBO, uMatrix, NoScript, and Temporary Containers.
This being said, I'm interested in LibreWolf and how much user.js manipulation they make unnecessary.
I have argued with @pfdietz about this before. In the zeal to make the point the majority of leading edge heating arises from the dissipative effects of shocks, they make statements that have to be very carefully parsed to be correct.
You are right. Isentropic compression will result in a higher temperature of the compressed fluid. This is undergraduate gasdynamics. In these supersonic flowfields with high shock strength though, the shock acts as a very dissipative compression mechanism. Behind the shock is a compressed fluid that is much hotter than it would be if compressed to the same pressure isentropically. Shocks are dissipative, like friction, but shocks and friction are not the same thing.
So unless you remove heat from a perfect compressible fluid being compressed (i.e., via a non-adiabatic process), it will always be hotter post-compression. It's just that the compression and heating that shocks effect causes much greater heating than the isentropic case.
In what we call "acreage" where the forward-facing area is limited (e.g., upper surfaces of wings and vehicle bodies), other effects, including turbulent skin friction heating, can dominate the local heating rate.
It's still a proprietary license that rejects the most basic principle of open source, which is the ability of anyone to use and modify the software.
Anyone is able to to use and modify the software, it's just that if your entity is large enough, you don't get to use it at zero compensation to the licensor.
The reason I would expect more FOSS advocates to embrace it is that other than this or a limited few other models (e.g., open core, commercial licenses to relieve GPL copyleft terms), what other avenues do they propose to exploit to ensure developers/maintainers are able to fund continuing development and maintenance of the software commons?
It's not like typical proprietary licenses to binaries where even if you pay, most likely you won't get the code (the exceptions are a low proportion of all proprietary licenses). "Shared source" as MS seems to define it makes you prove you're in one of their qualifying groups before you get to see the code - i.e., it's not like it's up on GitHub. And there are likely penalties if you share the code.
Shareware was also rarely distributed in source form, often had nag mechanisms/crippling, and didn't tend to distinguish between personal or non-commercial users and large institutional users. So I don't think "shareware" is a great categorization of this either.
My off-the-cuff label for this is a "Source Openly Available" license.