/tech/ - Technology

I've been reading alot about open access lately and the push that existed in the early days of the internet and how close it was tied to open-source software.

Unfortunately the monopolization of internet and there of the data collected via the internet is status quo in capitalism. Challenging the standards by providing open access, flips this monopolization onto its head.

The problem comes when others build proprietary software that cannot be or exist on "open" software. For arbitrary reasons. I don't belive that windows will one day become open, or provide open access, but one day open access resources will be on the same level of windows to provide legitimate competition outside of hobbyist.

>>30211
Are you keeping any cool minecraft tnt grief plans on your pc?

And specifically we should focus on breaking network effect. Stuff like steam's proton, federated social media, and even in-browser bookmarks and linktree-type sites and neocities cut away at the bars that keep people using proprietary stuff.

More of that and less preaching stallmanite asceticism. Key technologies like that make the difference between FOSS being the "alternative" vs FOSS being the primary and obvious option by which proprietary implementations are simply toys to inspire further FOSS development.

>>30223
It's weird because while steam itself is proprietary, it neatly eliminates the biggest reason why normies don't adopt open-source systems: gayming. The cumulative effect of increasing the userbase is still a net positive overall.

>>30223
yet paradoxically steam is making FOSS stuff for gaming possible, so you needn't be so stallmanite just yet lad

>>30217
>proton
qrd what it does on top of wine? is it just a valve-specific winetricks?

>>30211
>he thinks Linux doesn't glow
cope and SElinux.
You cannot program your way out of social antagonisms.

>>30213
pretty much all closed internet services are run off the back of free/open source software. moreover, as even the GPL people themselves have recognized, the current free/unfree software distinction doesn't matter: the real problem with most of the modern web is that it's designed around a client-server relationship with the user. That is, even if the software is free, the software is run entirely on someone else's hardware, so they're in control regardless. We have effectively reinvented the dumb terminal in the form of the smartphone.
If you could download and modify the Facebook source it would mean less than nothing because the value of Facebook is not in the software, but in the social networks that run across the instance of Facebook owned by Facebook itself. You can download Tinyboard, you cannot download /leftypol/.

>>30217
federated social media is a meme. fundamentally, you cannot program your way out of social forces.
the practical solution if you want "good" social media is to accept that they wind up being petty potentates of their owners, and try to promote them at the correct scale for that kind of thing. an imageboard can be a closed-source dictatorship run by one man and his friend, and if the posts are good then the posts are good, and if that man goes nuts and deletes all the good posts, you should leave, because there should be 50 other options. this is a social problem, only incidentally a technical one.

you've also, more importantly, got to set out to make something good. if you try to make ethical facebook you will fail. if you make a neocities because ideologically you ought to have a neocities (which just links back to your twitter), you'll mostly have failed. you need to make something good. "content" for want of a better word is not optional, "content" is all that matters. if you don't have content, you can't bait people into the medium itself.

the chief problem with FOSS-as-FOSS, in purely software terms, is that it doesn't give a single fuck about ux. we've known for decades that the average user likes to explore options in a graphical interface, but we still get fed either "uh, read the manual, use the terminal and edit text files" or "there's only one button, i designed this for literal chimps, if you don't like how it works don't use it", because making a good user interface is a difficult and valuable skill - but it isn't valued in the FOSS "community". once again, this is a social problem, a bunch of elitist jerks shooting themselves in the feet. sadly, they'll take the entire personal-computing revolution with them.

>>30338
>the average user likes to explore options in a graphical interface
which is a completely braindead approach to interface design and fundamentally breaks a software-as-tools workflow. you can't "explore" your way into understanding svg files or media encoding options. software often exists to solve hard and very domain-specific problems, thus an inexperienced user who hasn't read the manual will at best only have a vague sense of what a program does, which only leads to more problems in the long term.

you only need to look at specific niches like machine-aided translation to see, that expert systems, software that doesn't bend over backwards to be "user friendly", are still being made and for a good reason. despite the proliferation of visual studio and similar monolithic IDEs, there's a market for https://www.slickedit.com which is like emacs on steroids with an enterprise coat of paint. even though many foss developers lack a lot of experience in ux design, there is obviously something very wrong with the current state of the art, looking at the windows, osx and gnome software ecosystems specifically.

>>30340
you don't need to understand SVG files on some deep level to draw them in inkscape (the ultimate purpose of an SVG file, you may remember, is not "to understand an SVG file", it is to be a graphic), and similar is true for media encoding, which is only really relevant when importing or exporting from a graphical piece of software. (say, a film editing tool or media player).
there's nothing braindead about laying out your interface so that where things are is obvious and intuitive. an inexperienced user can get up to speed with - say - blender relatively quickly by running through an eclectic mix of tutorials and UI-exploration. Blender's not even a very good UI, but it's an the upper end of domain-specific tasks a non-programmer is going to be performing. blender would not be improved by removing all the buttons, adding a text window, and getting really cunty when people complain because replacing "add cube" with having you type "mk q." is CLEARLY faster and explained CLEARLY in the manual. (well, the mk command is. that q means cube is obvious, so we don't explain it.)

the current state of the art is terrible. it is probably path-dependently terrible. contempt for users, an overwhelming willingness to say "the user is wrong", is one of the reasons it's so terrible. when developing windows 95 they found that users liked to drag file icons onto folder icons to put a file into a folder, an obvious, intuitive inference from how a graphical interface works. this wasn't what was designed: you were supposed to open the folder, then put the file icon into the folder window. microsoft did something that no modern programmer would do: instead of telling the users that they were wrong, they re-wrote it so that you could drop icons directly into folders. normies aren't unreasonable, developers are.

>>30341
>mk q
Here is a sox command from the manual:
>play -n -c1 synth sin %-12 sin %-9 sin %-5 sin %-2 fade h 0.1 1 0.
1
You won't have any idea of what it does on its own, but you should get the general idea that it synthesizes sine waves of multiple frequencies and applies a fade effect. The specifics of the synth and fade options is what the manual exists to explain. Dedicated modular synthesis programs, which allow you to graphically lay out the signal chain and come with more builtin configurations exist, but for playing an 'A minor seventh' chord with a pipe-organ sound, this is entirely adequate.
>microsoft did something that no modern programmer would do
I don't understand where you're getting this from. Modern UX overwhelmingly caters to the hangups of current entry-level users. Artificial loading bars and delays exist, so they aren't startled from something happening too fast. Menus are hidden behind some "hamburger", there's an incessant smooth scrolling feel to everything and items takes up so much space you can only see 6 options max at a time. In some cases you can't even select options as text, but have to drag around several graphic representations of program state to accomplish anything. I haven't heard anything about removing "drag file onto folder" functionality from windows.

>>30342
For my money, I'll stick with a piano roll unless I'm generating the earlier command elsewhere - and I'm a fast typist.
>Modern UX overwhelmingly caters to the hangups of current entry-level users
exactly: entry level users, not intermediate level / average users. this is the friendlier of the janus-faces that contempt takes, imagining that the user is some kind of subhuman chimp who can't be trusted to do anything - but pandering to this instead of deciding to disregard them. in reality, entry level users become intermediate level users very quickly, and intermediate users find themselves strangled by these restrictions. fake load times, over-large icons and menu options, inappropriately hidden options, and bizarre breaks with the general principles of desktop GUI operations are all a marker of contempt, not of accommodation. instead of doing the hard work of thinking about how a human being of average intelligence will interact with the system, they set themselves the easy task of butchering the thing until it could be operated by coin flip. (occasionally with a little proviso that, if you really want to get anything done, there's always the command line.)

the purpose of the example is not that someone would like to remove the functionality (although some would say: what is the use case? why not just mv file /fuck/you ?) but that the mindset that lead to it being added is all but absent. contemptuous modern designers would take one of two approaches: they would disable folders entirely, assuming users were incapable of understanding the concept, or they would tell users that they were doing it wrong. they would not embrace the fact that the natural affordances of the system they designed lead to an intuitive way of performing a task and modify the system to take advantage of this. (what a mad suggestion - that the programmer exists to make the program serve the user, rather than the user having to do as the programmer says.)

people used to care. i mean look at this: https://andymatuschak.org/files/papers/Apple%20Human%20Interface%20Guidelines%201987.pdf and tell me any modern designer actually puts this much thought into their work or has this much respect for their users:
>The Apple Desktop Interface is based on the assumption that people are instinctively curious: they want to learn, and they learn best by active self-directed exploration of their environment. People strive to master their environment: they like to have a sense of control over what they are doing, to see and understand the results of their own actions. People are also skilled at manipulating symbolic representations: they love to communicate in verbal, visual, and gestural languages. Finally, people are both imaginative and artistic when they are provided with a comfortable context; they are most productive and effective when the environment in which they work and play is enjoyable and challenging.

neither a command line full of gibberish nor a hamburger menu with two options provide the user with what they deserve, what apple circa 1987 knew they deserved, what apple and everyone else has long forgotten.

>>30343
a quick follow up, because the seers at apple have a message for the hamburger hell designers:
>The user, not the computer, Initiates and controls all actions.
>People learn best when they're actively engaged. Too often, however, the computer acts and the user merely reacts within a limited set of options. In other instances, the computer "takes care" of the user, offering only those alternatives that are judged "good" for the user or that "protect" the user from detailed deliberations.
>On the surface, the concept of computer as protector may seem quite appealing, but this approach puts the computer, rather than the user, in the driving role—something quite at odds with the basic philosophy of the Apple Desktop Interface.
>In the Apple Desktop Interface, if the user attempts something risky, the computer provides a warning, but allows the action to proceed if the user confirms that this is what he wants. This approach "protects" the beginner but allows the user to remain in control.

moreover:
>Even though users like to have full documentation with their software, they don't like to read manuals (do you?). They would rather figure out how something works in the same way they learned to do things when they were children: by exploration, with lots of action and lots of feedback.
>As a result, users sometimes make mistakes or explore a bit further than they really wanted to. Make your application tolerant and forgiving. Forgiveness means letting users do anything reasonable, letting them know they won't break anything, always warning them when they're entering risky territory, then allowing them either to back away gracefully or to plunge ahead, knowing exactly what the consequences are. Even actions that aren't particularly risky should be reversible. Tell the users about any exceptions to this rule.
>When options are presented clearly and feedback is appropriate and timely, learning is relatively error-free. Alert messages should therefore be infrequent. If the user is subjected to a barrage of alert messages, something is wrong with the program design.

>>30343
>in reality, entry level users become intermediate level users very quickly
Only if you force them to actually *learn* the software. The current situation incentivizes searching for the word closest to what you want to do in the menu and googling for video tutorials if that doesn't work. Good software positively requires awareness of the larger problem space and not just a few individual solutions. Using arrows at the edges of objects for resizing is a good use of a graphical interface, now image if instead there was a "resize" menu options with two sliders for x and y, i would rather have a command line at that point.
>what is the use case? why not just mv file /fuck/you ?
All i see are people like you, ridiculing the command line, when boomers were objectively capable of using dos. Don't act like file paths are semantically any more complicated than folders themselves. People are just unreasonably allergic to text and a shocking number of phonetoddlers can't even wrap their head around folders more than 2 layers deep.
>For my money, I'll stick with a piano roll unless I'm generating the earlier command elsewhere - and I'm a fast typist.
This may be the case for some applications but not all. For simple actions using the mouse is usually faster and more concise, there are studies proving this contrary to popular perception, yet if you're talking about performing actions through a wizard, with multiple menus, checkboxes and sliders, the mental context switches graphical interfaces require can add up. See gimp vs convert -resize widthxheight or even convert -resize 800x600 -gamma 2 -level 5 -monochrome -depth 8.
>>Even though users like to have full documentation with their software, they don't like to read manuals (do you?). They would rather figure out how something works in the same way they learned to do things when they were children: by exploration, with lots of action and lots of feedback
I do both all the time, reading something from the manual, then experimenting if it fits my usecase, doing the second without the first would just be stumbling in the dark. WHY DON'T PEOPLE READ ANYMORE?????!!!!!

>>30340
>>30342
>>30348
You are arguing against pic A, whereas the person you're responding to is advocating for pic B

>>30348
Individual file manipulation with the command line is dire. For bulk movement according to a set of rules you see efficiency gains, but for moving a single file you wind up putting a lot of things in the users memory that should be on the computer screen. Oh, and I hope you don't make any typos :)

>>30351
There's actually a lot of software in between. I don't hate gimp for example, but the inconsistent menu navigation for teh sake of having graphical elements to interact with often trips me up. Pic B with its 5 rows of icons looks to suffer from this as well. The only thing worse than having to look for the name of the action you want to do is having to look for an icon with the right vibe.
>>30354
What is even the usecase for moving a lot of individual files to different directories? This isn't any faster in a graphic file manager, where you either navigate in between a two-part copy operation or open two separate windows. Passing file arguments to programs in the shell favors the current working directory a lot, it's like every directory is a desktop.

Furthermore in a lot of cases stating the file path is a natural part of the discovery process of a file. Either the program outright states where it keeps something like a log file, or you have to find/grep for it, in both cases the result is a file path. These paths are structured text both readable by a human or computer and i wish more programs took cues from acme to allow "special" actions on simple, transparent abstractions like this.

Like a graphic file manager, ls displays directories as a flat listing, yet because paths don't enforce the same limitation of clicking through a menu and connects the individual nodes to each others, users end up slowly gaining an understanding of the file system as a tree. Vidrel is literally the mental model you will build of a unix system. Any time some program needs me to select a file graphically, seeing the directories under root always gives me a feeling of decapitation. Anchoring these relationships within the users memory is a good thing, otherwise they'd be dumping their files *somewhere* and not know where to find them only a few hours later.

>>30355
A computer is capable of displaying a tree structure. Why should you maintain the tree in your mind when the computer is perfectly capable of showing it for you? (Indeed, to varying extents it already does.)

All real world objects have this property too. We build mental models of drawers, filing cabinets, etc, and we expect them to remain consistent - all without arbitrarily making the physical object disappear and keeping a mental model in our mind. Even blind people don't do that.

I may develop on this in the morning, but I'd summarise that it might even be worth thinking of as a matter of game design (not gamification) or interior design. The computer is a digital environment, and within an environment people can make some really very clever inferences - beat a game in half an a-press or whatever - if you design it well, with clear rules and useful feedback. If you design it badly, it's rather the same as designing a cup with the handle on the inside rather than the outside in the real world - you can drink, but why? A terminal does not usually give the necessary feedback to the user for them to treat the computer in this way. (Terminal based games, oddly, an exception)

Think of disparate file movements in terms of this metaphor - if you find a pair of trousers, a fork, a pan, some old papers, and various other junk lying around your physical environment, how do you deal with them? Would you be reassured or unnerved if I was to say some magic words and make them disappear - perhaps to their proper places, perhaps to Hades?

>>30356
>Why should you maintain the tree in your mind when the computer is perfectly capable of showing it for you?
If you've ever used one of those menus where opening a directory shows all its children, you should know how terrible they are. Selecting a file multiple layers deep always floods your view with unrelated crap. The program from the clip actually existed on IRIX and has a fairly modern version with a gtk port https://fsv.sourceforge.net/screenshots/ I agree it can help the user visualize files, i used it once or twice to that effect in the past, but it's even more cumbersome than a folding tree menu for regular use.

Why use arabic numerals, when we could just write tally marks, or perhaps a hybrid system like babylonian numerals? Because these symbols afford a higher-degree of abstraction, that allows us to grasp and express ideas more efficiently and a file path is one such abstraction. The things you need to do to interact with regular files and directories are precisely those you already care about: create, copy, move, remove, rename, link, feed to another program, etc; less actions than are displayed under the windows right click menu i'm certain.
>a pair of trousers, a fork, a pan, some old papers, and various other junk lying around
Sounds like the setup to an adventure game (>ᴗ•) Humans are great at adapting to conventions, provided they need to and aren't coddled by half-baked metaphors or being asked the same questions over and over again (that's essentially what menus are). Insisting on treating program and system state as various types of clutter only hinders an actual understanding of it.
>Terminal based games, oddly, an exception
You mean roguelikes? Technically nethack gives you exactly the same amount of feedback as rm&co relative to what it does. Rm only tells you if it fails, otherwise success is assumed. Nethack has to relay certain variable aspects of the game world, like FOV ar status messages, yet the principle behind it is the same, only show what the user can't already know. Moving onto a fountain doesn't ask you if you want to quaff from it, there are no visual flourishes to your actions, nethack doesn't even display the inventory beside the map screen like angband does.

>>30361
A more general reply follows, but hitting a few points quickly: I think folding tree menus are fine, as are ordinary "display the contents of this folder, its file path, and - if entered from another directory - a back button, plus a folding tree on the side" type file menus. both show you the menu in a context while - thanks to the file tree and back button - doing nothing to hamper understanding of the overall structure. The windows right-click menu, in different order, contains every menu option you list and more, provided you treat "open with…" as a stand-in for "feed to another program". Nethack doesn't have to output any feedback (you could just keep dying randomly with no explanation!), it does so because doing so is good design. You raise arabic numerals - but why use base ten as our default? if we counted using binary, you could finger count up to 1023…

Success being assumed is terrible UI design. It costs almost nothing to output "x deleted" - and in the cases where it does cost something (such as in a script that deletes a lot), it costs almost nothing to add a flag telling it to shut up. i assume, to you, this appears terribly redundant (why tell the user the computer's done doing what they asked?) and perhaps even in violation of the unix philosophy (rule 2!!!) - but there's value in redundancies. planes have two pilots for a reason. (a graphical interface doesn't need to pop up "file deleted", you can see it disappear in response to your actions without having to type "ls" and look for it)
i'm not assuming bad faith here, but i'm not sure i can productively convince you of my point. (which, going way back, is really about treating the user with contempt for using the computer "wrong", rather than UI design itself.) there's just too wide a gulf in assumptions about the default - it's like trying to convince a native japanese speaker that most people find it easier to work out the meaning of a sentence based on word-order rather than by marking everything with particles. (although i think this is only true thanks to English and Chinese tilting the statistics, whereas a preference for the convention of graphical interfaces is - i suspect - closer to "human nature". I mean, sticking with games, there's a reason there are more graphical games than non-graphical games! and, for all the terminal use involved, linux is still a much more graphical operating system than DOS or old-old-old Unix.)

as a result, you (quite naturally, perhaps) ask me to justify each little detail, each piece of feedback, each option displayed on screen instead of held in memory, which can be a useful exercise individually but ultimately feels rather like trying to explain why i'd rather feel a cup touching the table when i put it down - why not just put it down, remembering the relative height of the cup and the table, and assume success? or, if i can see the cup, why do i need to feel a bump? why do we need a sense of touch? what is the use case? (less is more!) and there are loads of other little details like this, not just in terms of feedback, or in taking the load off the user's memory by displaying things from the computer's memory: why (in principle, not technically) is it that terminal commands are generally one-way, while graphical commands can be ctrl+z'd if you fuck up? is it really necessary to explain that users like systems to be forgiving, and that a digital system is usually capable of undoing them?

in good faith, I'd recommend reading the apple UI guidelines pdf linked above. all of the general principles are fairly well explained - they're not right about absolutely everything, but they hit the main notes, and it's not just an anti-terminal polemic. most of it is about how to avoid making a bad GUI by the standards of 1987. i think that's more productive than me trying to reinvent the wheel by explaining that some menus are redundant and badly designed, others are very helpfully showing the user the options available to them. (would a paint program be improved by hiding all the tools available and expecting you to remember them?) based on my own background assumptions, which often diverge from yours, especially when my ultimate point isn't about UI design so much as about attitude: it is no good chiding the user for using the program wrong or for using the computer wrong, helping the user achieve their goals is the ultimate point of the whole enterprise. (and, more generally, only by adopting a user-first approach, and a user's-goals-first approach, can you [a] get people using free software, and [b] build websites and tools that draw people in, that have something of value to offer beyond being a gluten-free alternative to the status quo.)

>>30362
>is it really necessary to explain that users like systems to be forgiving, and that a digital system is usually capable of undoing them?
This is moreso a problem with systems than with interface design. Interfaces can only plaster over the ugly truth that the filesystems currently in use don't have proper versioning or an equivalent to garbage collection. I remember reading a blog post about the inadequacy of the "save" button in OSX and how it lures users into a false sense of security directly leading to data loss. The plan9 CWFS actually fixes some of this at a system level, by requiring you to commit desired changes to disk and leaving any one of these snapshots accessible indefinitely.
>ask me to justify each little detail, each piece of feedback, each option displayed on screen instead of held in memory
I understand this type of approach isn't the most useful in practice (as neither is hiring a ux design team is for a free software developer), but i want people to analyze software in these terms and strive to design efficient interfaces with the least amount of visual clutter (just like the gnome team wants devs to follow their interface guidelines).
>build websites and tools that draw people in
You seem to equate this with copying state of the art or apples design circa 1993. Developers should strive to find the interface most adequate to their problem domain, making it halfway palatable to a competent user would be the next watermark.
>why use base ten as our default?
Because it's a proven convention, that people are capable of intuitively understanding. The main issue i see is that within the capitalist framework of producing worker drones at the minimum of required competence, people aren't afforded the time to properly understand things. It's the type of policy which equates learning computers with sitting schoolchildren in front of microsoft office for a single period.
>I think folding tree menus
Maybe this is a difference in our workflows. When i'm sitting at the wine file explorer to select a file from one of my game directories, i always need to pass through the 'vg' directory. This isn't a problem with cd, as a game is something you typically know the name of, but in the menu this results in 80+ subdirectories i need to scroll through.
>there's a reason there are more graphical games than non-graphical games!
Any game that isn't action or puzzlebox oriented uses text as a major point of interaction. Think of RPGs, adventure games, Disco Elysium. Most visual novels use these tiny dialog boxes, but i really like the NVL type with walls of text. Not to mention the sheer mass of cyoa twine games or the enduring presence of interactive fiction interpreters.
>why do i need to feel a bump?
Because it is neither something naturally following from the problem domain, nor a sufficiently useful abstraction for reasoning about it. Imagine if someone pitched an oscilloscope that displayed phase and amplitude in the form of a clock face, it would sound like madness!

>Open source operating systems are software communism…building alternatives?
Silicon Valley anarchists are like the original anarchists who used hippie ass Christian theology to resist primitive accumulation…and like them, their "praxis" is immediately recuperated as part of capitalism. Utopian idealism is pre-Marxist pseudoscience from people who didn't understand the power of the proletariat (or actively denied it in favor of their individualist petite bourgeois narcissism)

>>30355
>What is even the usecase for moving a lot of individual files to different directories?
>>30356
>A computer is capable of displaying a tree structure. Why should you maintain the tree in your mind?
Twin Peaks fireman voice: "it is happening again"
<Lumpers and splitters are opposing factions in any academic discipline that has to place individual examples into rigorously defined categories.
https://en.wikipedia.org/wiki/Lumpers_and_splitters