spacelizard

25 years ago people would have said the same thing about OS kernels, and yet here we are. Some of the underlying problems I see are that the game industry is still young and hasn't really standardized everything yet. Because of that, there is still ruthless competition between the hardware and GFX card vendors. Vulkan is a step in the right direction, but it will obviously take time for it to become adopted.

A lot of it is also driven by the popularity of consoles and mobile devices which are still largely locked-down walled gardens. They intentionally make it difficult to share code between platforms too. But, soon enough game developers will get sick of writing the same code over and over again, just as OS developers did in the 90s. Once this happens you'll start to see a lot more ad-hoc code sharing which will pave the way for more engines being made free software.

It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config files across the datacenter just isn't an option.

I remember when they first released it as free software, it's come a long way since then. It's remarkable to see how much traction they've gotten. Bravo!

I think it is more important than ever that games aren't built on top of proprietary software. I am constantly hearing people complaining about:

- Restrictive DRM ruining the experience

- Servers being suddenly shut down with no recourse

- People who implement their own servers being threatened with legal action

- Popular features being removed

- Communities shifting focus just to appease advertisers

- Spying features being (ineffectively) implemented in order to prevent cheating

- Exclusivity deals, and authors just flat out refusing to port things to other platforms

- High turnover, high stress working conditions, lots of duplication of effort for little gain

Not that any of these problems are specific to games, but the point is that these things don't generally happen with free software. I appreciate the vast improvements we've made in microeconomics to get games to the point where the average quality of a game is incredible and the price is ridiculously low, but the whole thing stinks of a bear market right now.

If we could engineer a chemical agent that forces people to love each other, couldn't we end all armed conflict right then and there?

If you ask me, the GIMP-vs-Photoshop debate has become so much of a dead-horse-beating exercise, to the point where I no longer believe that it is fair to compare those two programs as being anything similar. The only comparison I can draw is this: As with any large and old programs, they both will suffer irrelevance in the coming years anyway, and hopefully become displaced by newer and better products. Disclaimer to make me not sound like a complete idiot: I haven't used Photoshop in many years, but I use GIMP infrequently for mundane image editing tasks.

It's actually not that ridiculous or difficult to reduce your proprietary software usage. I also think it's a fallacy to say that free software is generally low-quality -- let's not forget that there is plenty of shoddy, badly-supported proprietary software out there too. The worst of it also tends to include spying and malware.

Granted it was much easier to avoid proprietary software around 10 years ago before SaaS and smartphones took off. I think the community has been slow to adapt to these changes, but that isn't a reason to give up hope.

I get the appeal of 3D touch but it has absolutely no discoverability - this feels like a complete setback in UX design. Apple used to be known for having UIs that had a lot of visual cues and didn't hide features from the user. However it seems they have done a 180 on that in recent years.

I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you.

The echoes of Golang hype right now are somewhat ominous. A few years ago it was "concurrency primitives are going to change your life" and now it's "lifetime/ownership primitives are going to change your life."

I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.

Brings back fond memories of the first time I learned C, when I really had to dig into what the difference was between storage durations (auto/stack, dynamic/heap, static, thread local). It makes it increasingly important to think about when an object is going to be stored, and for how long. To me this is still a really useful concept that most high-level languages seem to have all disregarded in favor of extremely eager GC or refcounting, with the exception of Rust.

I can think of a few:

- Have the employee agree to grant a royalty-free license to all relevant inventions made in the appropriate time period

- Have the employee forfeit all inventions in the event they initiate litigation

- Or better, sign a mutual patent disarmament clause (probably my favorite option)

Going back to the core of the issue though, I would not trust investors who insist on appropriating the rights to any and all inventions they can. The article tries to frame this as a legal protection strategy, but they don't need ownership to do this. The only reason they insist on it is to try and pressure the founders into squeezing maximum value from employees while giving back as little as they can in return. Unfortunately this behavior is quite widespread.

It's disappointing that there are no conventions or legislation to rectify this situation. I have several side projects going right now, and it gets frustrating going to interviews and being asked to give up all of it just for the supposed "privilege" of being able to write code for a larger company. The solution I've found is freelancing, but this has the problem of not really providing steady work.

Most educational systems are rooted in child-care, not in actually educating students. And the ones that do have the resources to properly educate students are often so entrenched in politics and status that they become better conduits for indoctrination instead of empowering students to better make decisions themselves. Like any old organization problems, it is going to be incredibly difficult for them to shed that history.

Yeah I think this is the real win - the examples in the paper don't really cover any of the real reasons why someone would use functional programming. The places that I've used C++ lambdas a lot are callback-heavy code, i.e. things with a lot of asynchronous I/O, multi-threading, etc.

While I don't doubt the validity of the argument that it takes longer for a programmer to write correct lambda code in C++ (I have been using them since C++11 was released and still forget the capture list syntax sometime), it's not much more than an academic exercise to take some iterator-based code and replace it with higher-order function calls. It's unfortunate that all the tasks seem to be based around doing that though. I do think it is still reasonable to do this in C++11 once you know how - with -O1 turned on you can get basically the same code spit out using std::transform, std::accumulate, std::for_each, et al, as you would using a for loop.

It's also unfortunate to note that, at least in g++ and clang, there is still significant advantage to using lambdas over std::function and std::bind. Lambdas typically end up being faster in both compile-time and run-time, and end up generating less code. For these reasons I've found myself using them a lot more, especially anywhere I would have done some type of currying. This I do miss somewhat, but it's still leaps and bounds ahead of something I would have written in C++03.

The same is true of literally every piece of software ever distributed regardless of license.

It would be nice to see a future where all applications have some concept of peer-to-peer networking and would be able to talk to each other. My hope is that this leads to blurring the line between having separate architectures for server, desktop and mobile apps, to the point where the only differences are reflected in the physical limitations of the device.

It's interesting to see how modern public cloud businesses seem to have borrowed a lot of their business models from old timesharing systems of the 70s. From there it's easy to analogize timesharing systems being killed off by personal computers to cloud computing being killed off by personal cloud.

Personally as a fellow free software developer, I take whatever opportunities I can to look closer at what value the software is really providing for the user. Is your primary user actually interested in the freedom and community the software provides, or are they just looking for "Pro Tools on GNU/Linux" with a low price tag? It's probably a combination of the two for most users, and as you have found there is tons of tweaking that can be done to optimize for the middle-ground. I personally choose to lean more towards optimizing for freedom and community, but the downside to this is it requires more infrastructure to support it.

From the download page it looks like your anchor point is a one-time $45 for unlimited upgrades. This is already fairly cheap for DAW software, but I would be interested to know which of your pricing options actually does generate the most revenue. That would probably give you clues as to how to build a stronger free (gratis) version that doesn't reduce overall value for the user. Subscriptions being popular means you can probably consider paid add-ons and services. User wants to use proprietary plugins? It's added maintenance costs, make them pay for it. One-time purchases being popular means you probably need to pursue sponsorships. Unfortunately I don't know a good way to do this at scale without either A) embedding obnoxious advertising, or B) finding generous corporate benefactors. Everyone obviously wants option B and option A sucks for everybody. Whoever can find the equilibrium in between these will get rich.

I also want to add that I tremendously respect what you're doing and how far you've come, and that I probably would not be a musician if Ardour did not exist :)

Yes you can, but that's beside the point. For a complicated application like this there obviously is value in both the source code and the pre-built binaries. I think people would be a little less annoyed if this didn't seem to be copping sales techniques from sketchy outdated proprietary business models (Prices not posted up front? Free version has time limitations??) and instead did something that was more sustainable. What this would be, I'm not quite sure of. Part of the problem probably is that desktop applications are not really a big market anymore. Maybe they should run a proper marketplace for free (as in freedom) audio plugins?

Thanks Gavan! This is exciting, I've been waiting for this for a while. The code looks super hacky, but that's to be expected :)

Hopefully it gets ported to Mac and GNU/Linux soon. If not, I'd definitely like to try and port it over when I get some spare time. Cheers!

I think the point is that sociopolitical struggles continue outside of what we do as free software authors, and so we regularly need to re-examine the greater context in which we operate.

A lot of people forget that VCs are salesmen trying to sell a financing product. These come with the usual risks.

>DRM will be built because the content studios demand it, and the studios hold the content which everyone wants

Why do you believe the copyright holders (or the browser makers) are the ones who potentially hold absolute power in this scenario, rather than the users? Any DRM is an unsustainable system, EME is not going to change this. I also have strong doubts that EME will do anything to push the so-called "content industry" towards better sustainability as you suggest it will. There is still zero incentive for any knowledgeable user to buy into it. If anything it will just make the system more complicated because of the proliferation of even more competing, incompatible DRM systems that only work on certain devices with very specific configuration requirements.

I agree that some of the ridiculousness in the DMCA is part of the problem, but this isn't going to be solved by building more walled gardens, it's going to be solved by thinking about how it can actually benefit the user in the long run.

From their FAQ: https://neo900.org/faq#peripherals

>We unfortunately cannot provide free baseband modem firmware, as there is no option available on the market which would be able to fulfil this requirement. Even if it existed, it would bring very little value to the users, as operating a radio device with modified firmware on public networks without recertification is prohibited in most jurisdictions of the world and privacy concerns in cellular networks are mostly related to what happens on the network side, not inside the device.

I don't have any more information than this. If someone can quote specific FCC regulations to back this up, I would find that very interesting :)

Not quite, but you can come close. I have Cyanogen installed on all my Android devices and I try to use as little proprietary software as possible. However I am patiently waiting for the Neo900, which is a free (libre) hardware design based on the Nokia N900: https://neo900.org/

According to them, there are unfortunately no baseband modems on the market that can legally have their firmware distributed as free software. Their workaround is to keep the modem as isolated from the CPU/RAM as possible.

The tendency to just remove features without so much as a word of warning to users seems pretty popular these days. I think it is most commonly seen as part of a push to remove complexity from the program. Unfortunately this mentality can also make it seem like creating and maintaining channels that warn users of upcoming changes are unnecessary pieces of process complexity.

Of course all that is accomplished by this internal simplifying is offloading that complexity to the user who will then complain and/or seek out a way to do what they want to do on their own. Users searching for undocumented features is probably a good thing and should be encouraged. In the case of developers unwilling to communicate properly, all the users can do is try to fill in the gaps themselves by guessing and speculating on what the developers are up to. This, I don't think is such a good thing, and it's somewhat embarrassing when it happens with a social media company whose main product is a communication tool.

The use case I am thinking of now seems to be more appropriate for apps like GitLab where sharing URLs from within the app might be useful, for example sending someone a link to a file like this:

https://d85snt1c8mqgrfxcd2o1.blah.company.com/gitlab/repo/bl...

Another issue with this is because of the navigation being done with frames, those URLs are somewhat hidden from the user. I have some thoughts on this, but they may be worth saving for the issue tracker as this appears to be an issue with the GitLab port and not Sandstorm itself.

I just installed Sandstorm yesterday and I like what I see so far -- hope I get some time to submit some pull requests. It's looking like a great option for smaller companies that want to stick to free (libre) software.

One feature that I think would be cool is if there was a way to associate a custom subdomain with a grain rather than the auto-generated stuff like "xh37vmw0h5276mj7h5eh.blah.company.com". Being able to host at "docs.company.com" makes link sharing a lot nicer for everyone!

Another company offering SaaS products is not a plus by itself either. The idea of "pay us so you don't have to push upstream fixes" is just another spin on the usual marketing agenda for cloud-based companies. Either way when running a business you need to consider what kind of infrastructure you're investing in.

Then the users need to be educated about those things too.

Don't you think it's a bit odd that the premise is to "trick" users into using Firefox by luring them in with promises of Netflix support? What's the point of this, and what precedent does it set? These are the issues we need to think about, rather than just saying things like "oh no Mozilla is losing all it's users" and other silly doomsday predictions.