No, I would argue that from the three main ingredients - training data, model source code and weights - weights are the furthest away from something akin to source code.
They're more like obfuscated binaries. When it comes to fine-tuning only however things shift a little bit, yes.
"Others are questioning whether or not this kind of layout is needed on the web at all — they aren’t sure that well-known websites will use it."
Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard? I know this sounds toxic, but I would argue that approaching public design this way is ultimately more toxic wrt the outcome and those affected by it.
Or maybe I misunderstood that part since everyone seems to not be bothered by it at all here...
> Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard?
That attitude is rather critical and important to the discussion.
I don't think it's the browser, or the standards bodies, responsibility to have built-in support for every possible feature we can imagine. Instead, the standards need to be simple and extensible so that that libraries (Javascript or WASM) can do creative layouts. (IE, instead of waiting for Masonry layout in CSS, you should be able to grab a Masonry layout library and include it with your web site.)
Otherwise, we're building a system where the standards (CSS in this case) are so complicated that it's getting harder and harder to implement the standards; and are too inflexible to support what tomorrows' developers can imagine.
Why? When developing standards it's very good to have good gatekeepers.
Not everything should be built inside the browser if you can achieve the same with existing technologies like JS.
Otherwise your browser(standards) might become too complex.
For what it’s worth, I found masonry layout always detrimental to my use of a site. I would prefer CSS not to encourage it by providing built-in support.
Why? Any feature is a liability, so it's good to question whether a feature has to be implemented, and whether it should be in this way and position, or maybe somewhere else.
I assume, with "well-known", they mean popular. Which means they (also) measure the worth of this feature by the number of users which might benefit from it. This is a very legit metric for this kind of situation.
I mean the actual point of the article is to ask everyone, not just "well-known" examples.
So it seems there were some reasonably forces in the discussion that align with my stance without the unnecessarily antagonistic (and rhetoric) primer I should've probably left out.
Seems like a good approach to widen the discussion and improve the design.
I can totally understand the quoted comment. I mean, we are talking about CSS as a language here. Anything that is formalized is expected to be implemented and supported by browser engines and vendors. Browser engines are already extremely complex, so it's fair to think closely about formalizing new things when it's not apparent that there is a big enough need.
I'm not claiming this is the case with the Mansory layout; I just understand that adding unnecessary complexity for a small target user base is a valid concern.
Well-known == highly visited == native implementation will have large accumulated impact on end users (their performance, energy consumption, improved usability ...).
This take is imho dangerously conflates personal taste and motivation with "should a heavily generalized and clearly purposed layout system be complicated with some magic keyuword options to serve your specific intents?", and misappropriates the assumption that people like and use this form layout as a reason to approve the latter.
Questioning whether something new is actually needed is absolutely worth doing, so long as it’s done respectfully.
This is a standard that affects billions of people and many implementations. It’s great to ask if something is really needed or if it’s just adding bloat.
We shouldn’t just grow the standard without first asking if the growth and added complexity carry their own weight. If someone proposing something can show that, then wonderful.
But yeah, just straight up trying to block these people from being able to ask these questions totally is toxic. As long as they’re asking and participating respectfully there’s no need to be a jerk toward them.
It’s fine if you disagree with the premise of the question. But it’s also fine to ask the question, since presumably the asker wants to know the feature would get enough usage to justify its addition to the specification, and an easy way to show it gets usage is by showing some well-known sites would use it.
But what is not fine is trying to exclude people from the conversation and silence them just because you have a disagreement.
And honestly, that's a ridiculous claim. Two very popular websites I can think of right away are Pinterest and VSCO. (Perhaps VSCO on the web isn't as popular as the mobile app, but the company continues to use masonry as the design evolves.)
The line suggests the opposite yes. That's why I take issue with it.
There's nothing easy about nix. Maybe flox makes it easier, but I am so burned out by screwing around for countless hours with nix I'm not even going to try to figure out if it's true.
The fact that my experience with nix has historically been _so_ difficult, I fear even something that claims to make it "easier" will not be able to deliver -- my aversion has everything to do with nix, and little do with any product which claims to improve it. Consider it guilt by association.
For me, it doesn't simply need to be easier, it needs to be usable. I lack confidence a product which is an abstraction layer is going to solve that for me, because I have a personal inability to understand the underlying system.
Maybe you need to try it out rather than casting doubts about a product you haven't tried yet? Pre-emptively doubting claims based on your past experience with a tool Flox claims to solve seems like a poor way to go here.
For what it's worth, there are a number of options in the Nix space that really do solve for its complexity like Devbox and now Flox.
If you still use it, my best suggestion is to use a github search for 'path:.nix TERMs' when you run in to issues. It's likely someone already has that custom package, or an overlay to fix that missing compile option, or whatever else it is that you're looking for. I find reading other peoples solutions also helps with understanding and solving related problems.
I'm in no means claiming Nix is perfect, but coming from other distros to NixOS I really appreciate the ability to reboot to a new generation and then reboot back if I run in to issues. To do the same in Arch I had a bunch of 'snapper plus manual steps' to accomplish the same.
A month ago Nvidia had a grant program running to get rid of refurbished^w^w^w^w donate 1-4 Titan Vs based on a 1-2 page application [1]. When my university started offering a CUDA course we got ~15 top of the line GTX cards sponsored by Nvidia. Buying 100 GTX1080TI with 11GB with supporting hardware is in the range of 100 thousand Euro/USD (before applying education discounts and asking for sponsorships). Not money spent on a dime, but not outrageously expensive either (the article mentions OpenAI spending millions on cloud GPU resources, compared to that spending 100k on something you get to keep is nothing)
Why can't they afford it? I remember when I worked at a physics lab at University and each team had many pieces of equipment each costing more than $100k. You'd get quite a lot of compute for that kind of money, especially since AI research doesn't need any other equipment.
I edit my sources and remote configs exclusively in vim-likes since ~2004 (full time sw dev) and never experienced such issues. From my experience, typing or clicking speed requirement rarely exceeds that of thinking on your program. I hit esc often, but not too often, and it is not too far.
I’m not against caps->esc mapping in general, but for me this would have little to no value plus non-standard layout, which is minus, since I’m not office-only guy.
This exactly - complete recountability and the fact that there actually are independent volunteers recounting are the only assurances of a transparent, legitimate voting system. Black boxes (and computer systems by their nature are black boxes) introduced into this system will always void its transparency.
They're more like obfuscated binaries. When it comes to fine-tuning only however things shift a little bit, yes.