HN user
It's not a cult, 40 is just a sweet spot between performance, battery life, and comfort for a large number of demanding 3D games. If you often play in docked mode, the battery life doesn't mattery so you can probably achieve 50 or 60 in some modern games.
The bigger the display, the easier it is to visually detect a difference in refresh rates
Why would users need to re-purchase everything just to adopt a different store launcher as their primary platform? GOG Galaxy for instance interfaces with most existing stores and friend networks. As long as you're buying games on PC, you're not really locked into much of anything.
That said, buying certain games can lock you into using Windows. So there's that. But it's far better than buying games on modern consoles, which force you to use some special-snowflake hardware just to access the game you bought.
It's impossible to completely prevent all classes of lock-in, but it can be minimized. I would argue that my personal lock-in is minimized, across the axes I care about, by buying everything from Steam and GOG. No hard Windows dependency, no silly hardware dependency, and I'll almost certainly still have access to my games in 40 years.
That Steam was a first-mover is basically irrelevant. PC gamers are a particularly demanding audience and they will abandon your product in a heartbeat if a vastly superior one comes along. For instance, TeamSpeak and to a lesser extent Ventrilo and Mumble more or less dominated voice chat for many years. Then Discord came along and those older products became irrelevant practically overnight.
Valve uses its 30% cut extremely effectively by continuing to invest in the happiness and convenience of its customers and, just as importantly, its developers. For instance the profits of smaller developers dramatically increased after the new discovery/search features landed, enabling exactly the kind of people who would love your game to find it easily. Contrast that with every other store where it's basically impossible to find anything but the most mainstream top sellers.
Maybe Epic could afford to actually make the Epic Games Store a useful product if they took a higher cut of sales?
The cost of translating input calls from Linux to Windows APIs through Wine/Proton is so much less than the cost of rendering a single frame that it's effectively 0. The only real overhead Wine/Proton might be adding is in the rendering pipeline.
As Steve explained in the video, the Steam Deck's input-to-photon latency is lower than the Aya Neo's simply because it has a much more powerful GPU.
The only real way to test if there's any extra input-to-photon latency would be to compare the exact same game on a Steam Deck running SteamOS to a Steam Deck running Windows.
What features does Windows have that Linux doesn't?
The only one I can think of off the top of my head is HDR support, but that wouldn't affect these benchmark results.
That's just because no one actually uses HaikuOS or RedoxOS (no offense to these wonderful projects of course). If these came even remotely close to the popularity of Linux, you'd have remixes, spin-offs, and eventually full-blown distributions.
You can try to prevent it with project structure, but even something really unified like FreeBSD ended up having derivatives like GhostBSD as well as full-blown divergent forks like DragonFly BSD that are not necessarily compatible anymore with upstream.
The Link hardware just wasn't necessary anymore once the software became good enough to run on any device as an app. I have Stream Link on my TV as an app now.
This is news to me. What is an example of a portable gaming PC that has flopped? I'm honestly just not aware of any major company trying to make one.
As for Valve hardware, the only clear flop was Steam Machines -- which weren't Valve hardware at all.
I think it's odd to focus purely on the mass market success of Valve's actual hardware (Link, Controller, Index) since these can all be considered experiments by a company that can afford to fail, and since these have all been widely praised as the best-in-category. Clearly they know how to make great hardware; they just haven't done anything mass market yet. Who knows, maybe the disappointment with Nintendo will fuel sales for the Steam Deck.
It's a 7" screen, so this resolution is comparable to an Apple Retina display in terms of ppi.
Playing PC games on a cell phone is painful. You can't even see half the game because your thumbs always obscure the screen to operate the touch controls.
The mere fact that NVIDIA Shield Portable didn't take off doesn't tell us much. It had poor design sensibility (i.e. it looked like ass, like some kind of portable Xbox designed in the early 2000s), and it ran Android, which lacks a compelling games library.
Steam Deck at least stands a chance, although I'm worried about the weight and the battery life.
However an optional is really just a list constrained to size 0 or 1.
What?
You wrote on ihateracket.com:
Which language should be used in a CS1? There isn’t very much research to suggest conclusively what makes the biggest difference in a classroom, and it doesn’t seem like the language debate will ever end.
But now you're saying there's a massive amount of research for Java and Python — so I think we must be talking about two different things.
I'm not clear that that's more than a theory.
It is less than a theory — it's my opinion based on my experience going through the edX How to Code series (closely based on HtDP and the design recipes). For example, sum types are taught as "Enumerations" [0], and the design recipe for enumerations looks suspiciously like "pattern matching in a language without pattern matching", as if to prime the student for a language that supports this more conveniently.
Yet, if the student learns Java immediately after HtDP, they will have no use for this knowledge (and probably forget it), as it seems you need some convoluted boilerplate like the visitor pattern to emulate a sum type [1].
Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that.
Given that the follow-up material to HtDP was called "How to Design Classes" and used Java [2], no I don't think this is a goal of (PbD's) CS1. I'm saying I think it should be to make the curriculum cohesive, and that HtDP is a wasted investment of the student's patience without related follow-up material. I really loved HtDP so I wish I could find such material.
[0] https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenu...
[1] https://stackoverflow.com/questions/48143268/java-tagged-uni...
[2] https://programbydesign.org/materials (You can see it mentioned but it doesn't seem to exist anymore when you follow the links)
I would argue that some research is better than none, and that some intentionality in the design of a curriculum is better than an ad hoc curriculum.
The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. If students are just going to learn Java or Python immediately afterwards, I think it's a waste.
I agree. I have been a very regular user of Webflow for the past eight months and it has given me a 10x productivity boost despite being capable of coding it all by hand.
It does have serious limitations though. Many times I have needed to tell clients: "you can't do that because it's not (yet?) supported in Webflow". For example, you can't have "lists of lists" (i.e. nested maps or loops in JavaScript), which makes a huge number of designs virtually impossible. There are also random CSS properties, like vertical text alignment, missing from the Webflow interface, requiring custom coding, and they have arbitrary maximum file sizes for a number of assets. With Webflow, you either stay within their limitations, or you have to do a lot of things in custom code embeds.
Despite this, I've found that, even with Webflow's brutal price structures, working around those limitations in order to stay on Webflow's infrastructure has generally been worth the pain compared to spending a whole lot more time/money on doing things by hand, especially because my clients have a tendency to completely change their mind several times during the process. I'm not yet aware of anything with a shorter iteration time — there's CodePen, but its hosting features are even more limited than Webflow's...
The way this article described Salesforce makes it sound like generic database frontend software, like a more powerful, complex, and customizable Airtable. I'd love to read a comparison of the two if anyone has used both.
Note: I've applied for SIBR funding in the past. Huge waste of time. Similar to an RFP, by the time a SIBR request is written, the preferred vendor has already been chosen.
This is misinformation. SBIR funding is the #1 source of early-stage funding for certain industries. Any startup developing a life-saving medicine or medical device is using SBIR for things like clinical trials. "The preferred vendor has already been chosen" is utter nonsense; it's like saying the government has already decided which drug is going to work.
To be effective at applying for SBIR grants you do need a good program officer. They will let you know whether it's worth spending the time to apply.
VC funding is completely inappropriate for early stage startups, and it's a last resort even if you're mature enough.
Aside from that, there are entire industries that VCs don't touch until after SBIR, such as life sciences startups, where you're looking at 10 years of R&D and regulatory approval processes before you can launch on the market. That's way too long for VCs.
I empathize with your general sentiment, but non-profits and governments exist to fill in gaps that the free market cannot.
I backed this. Visual data should be edited visually.
"Open process" might be a good term for everything else that goes into producing open-source software.
Free software is not about licenses; they're a very limited means to an end. If we didn't have copyright, some other means would be needed.
For freedom to spread, free software has to become faster, prettier, more convenient, and more intuitive than proprietary software. I would go further than this and say that the distinction between developers and users has to become fuzzier, so that anyone can edit software without needing to be a "developer".
Sadly, developers love their arcane tools because it makes them feel elite. And the FSF / GNU project participates in this elitism by continuing to promote such arcane tools. Software like GNU Emacs only meets the absolute bare minimum of "free software"; it empowers hackers but it doesn't empower the general public.
The next movement, whatever it will be called, needs to embrace open source licensing, and open process, and end user empowerment.
I don't understand why they shut this down before they even attempted to start charging money for it.
Even if treating this not as a roadmap to becoming a web developer, but more as a map of what an expert-level web developer might be familiar with, it's still scary.
Why does modern web development have to be so convoluted? Here is a wishlist of what I want from ONE language:
- A package manager like nix so that each project folder doesn't have to be hundreds of megabytes
- Static typing with minimally expressive (i.e. ADTs) type system, type inference
- Built in immutable data by default, so you don't have to pile on 3 different immutable data libraries
- A better alternative to HTML+CSS like Elm UI [0]
- One very high quality backend framework (exactly like Phoenix)
- One very high quality frontend framework like Elm but with better component reusability, that makes fewer allocations, and that compiles to efficient WASM
The benefits of a "one language to rule them all approach" should be extremely obvious to JavaScript developers who are following this approach with Node.js, React, etc. This huge mess of tools that they use now is a hairball of workarounds for JavaScript's many deficiencies. We essentially just need a better JavaScript.
This is a question of margins, so you're neither right nor wrong.
It normally isn't just 0.1% of sales when developers do get everything right, although whether or not the usual 1-5% of sales is worth it depends on the particular game, budget, and sales numbers. Linux support clearly wasn't worth it for Planetary Annihilation due to its low sales numbers, but a game with (1) high sales and (2) easy porting process would be leaving money on the table not to support Linux.
I mention the Steam runtime because this affects the Linux version to this day: I am unable to launch the game (on a fully supported system and OS, mind you) without deleting some files from their install.
He points out that a very large percentage of the crashes were graphics driver related
This was still largely related to the Coherent UI middleware and the strange way it was being used, as other posts have noted.
Linux is the perpetual scapegoat.
They selected a middleware, Coherent UI, that didn't work properly on anything but Windows. They also didn't make proper use of the Steam runtime, a mistake that continues to cause issues. Most games don't make these mistakes, so this isn't really representative of the larger state of Linux gaming.
It's worth pointing out that the devs did make a legitimately good attempt at making Linux/Mac support first class, by making a purely OpenGL engine for the game. But it seems they weren't aware of some other best practices.
Yes and no. OCaml already has one of the fastest production compilers in the world, acceptable error messages (better than Haskell's, anyway), a great REPL (utop), a high-quality and well-documented build system (dune), a powerful package manager (opam), and a very good language server for IDE integration (merlin).
What it's sorely missing right now is higher quality documentation output. Currently, it's hard to navigate the generated documentation (e.g., no search bar), it's not held in a centralized online location, and it doesn't do a great job dealing with complex module/functor hierarchies (especially in the presence of destructive substitution).
Unfortunately, much of what I described above doesn't come out of the box. To fix this, the OCaml community is seeking to emulate Rust's cargo tool via the development of the ocaml-platform: http://ocamllabs.io/doc/platform.html
An aside: I didn't know Java had good tooling. I know it recently gained a good REPL. But what is the official package manager, and where is the centralized repository for packages?
Example of OCaml's object system in use by the creator of OCaml: https://github.com/xavierleroy/cryptokit/blob/master/src/cry...
OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic.
Also, I like OCaml's extremely simple and direct syntax. I'm fine with F#'s implicit `in`, though it requires whitespace-sensitivity. I think ReasonML went in the wrong direction, cluttering it up with curly braces and ubiquitous tuple-like syntax for function arguments.
OCaml actually has excellent tooling — among the best — and some (but not many) great libraries. What it lacks most is great documentation...
I believe this class-oriented workaround is a side-effect of Don Syme's decision to strip out the OCaml module system from F#.
Every single binary that works on Ubuntu will work without modification on Pop!_OS.
That is not true for Debian. Some packages (like the .deb file for Chrome or VSCode) should work on any distribution that supports dpkg, but there are many packages that break compatibility between Ubuntu and Debian. Thus Ubuntu isn't just a customized Debian; it's a customization that creates a distinct operating system.