/tech/ - Technology★

I got used to navigating through the operating system solely through keyboard after a while - it's faster and I don't need to frequently switch between the mouse and keyboard for the most basic tasks. Linux isn't a hackerman branded operating system with a Windows core underneath, so don't expect it to behave the same way.

Oh and also, kill yourself.

>>1040450

no you kill yourself, fanboy

>Is that so hard?

Yes because Linux is a kernel. It would have to check which GUIshit is running (Wayland, Xshit or maybe even Android) and have a client for each of them.

When an error occurs and one of them is running it could output it over an own client window.

There is the issue. The solution is bullshit and that's what you get with thrown together shitpieces of different types of shit with independent shitvision.

>>1040450

>Windows core

OS X and Haiku can do that too.

>Oh and also, kill yourself.

Not OP but you first ;)

>"WHERE'S MY BIG BUTTONS, BIG WARNING DIALOGS, BIG TEXT AND BIG WINDOWS AND BIG FUCKING COCK IN MY MOUTH"

GUIs are a mistake

Linux is just a kernel, so it couldn't.

But talking about GNU/Linux, which is actually an operating system, it depends on the type of an error. Would you like to have shitty Windows-like error code x1092378rDh120n rc21VO, "Something have happend, we're trying to fix it" which doesn't give any clues or what? If a program isn't working as it should I just run it in a terminal emulator, and search the program logs. I don't need error windows jumping on me.

No. This operating system was made for essentially electronic typewriters. Unfortunately you can't make a pop up on a typewriter so that feature is off limits.

>>1040450

<it's faster

>We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

>Test subjects consistently report that keyboarding is faster than mousing.

>The stopwatch consistently proves mousing is faster than keyboarding.

AppleDirect, August, 1989

>>1040461

Salty Lincuck detected.

It's good to know whether your GUI application crashed or closed itself.

Especially on your unpolished OS.

>>1040463

OP here. I mean holy shit, I'm not expecting much. If a program can't find a library, is it so hard to display "File shitlib.so not found" ?

>>1040465

I remember fucking Windows 98 doing that already.

As fun as it is to frame a potentially interesting technical discussion as a series of unproductive complaints, insults, and holy war rhetoric, I'm actually interested to know if such a feature could be implemented, and if not, what prevents that from being possible.

I'm not too familiar with the inner workings of D-Bus, but that would be my first guess for where to look. Surely D-Bus must know when one of the processes connected to it terminates. Does D-Bus have access to the standard output of connected processes?

>>1040465

<inb4 a UNIX weenie comes in and says that it's better for the program to just run and crash when it needs it

The way GUIs for linux are made, it's clear that nobody put any serious thought into them. This follows because linux is primarily for servers, so desktop linux will always take a back seat. Still, the number of different distributions for workstation linux would make you think it was mature, when in facts it's a hacked together PoS.

>>1040473

The way this would be solved on any other OS is quite simple: each application developer would be interested in making his program pass a bare minimum level of usability, so he would implement the dialogue himself using a standard interface meant for the purpose. You could create yet another hack that would sort of work half the time. But it would leave you even more confused the 10% of the time the hack didn't work.

I'm damn lucky I like server software, so I can manage fine with linux. But I feel very sorry for all the people who do graphical work, and have to suffer through their choice of hell.

>>1040447 (OP)

linux errors are better than modern windows errors. linux gives useful information windows just some stupid something happened tier message that wont help at all.

>>1040484

>linux errors are better than modern windows errors

So what? You are stooping pretty low if you have to compare yourself to Windows to say you have better error messages.

This is not a problem with Linux but a problem with specific projects that don't provide a graphical dialog box for errors.

You should probably stop using that program and instead look for a more graphical alternative.

>>1040495

>This is not a problem with Linux but a problem with specific projects that don't provide a graphical dialog box for errors.

This deflection of responsibility and criticism is so common I can't tell if you truly believe this or if you're merely pretending to.

>You should probably stop using that program and instead look for a more graphical alternative.

So, the system doesn't provide decent abstractions for much of anything, but that's everything else's fault? The Linux kernel doesn't even implement something such as fsync() in a way that database programmers expect, leading to issues. When every program needs to have loops to use system calls correctly, specialized code to sanitize filenames correctly, or its own abstractions just to report errors graphically, what's the point of the underlying "operating system"?

>>1040447 (OP)

>Terminal show graphical error when there's a problem

>I want graphical error when there's a problem

?

>>1040508

> When every program needs to have loops to use system calls correctly, specialized code to sanitize filenames correctly, or its own abstractions just to report errors graphically, what's the point of the underlying "operating system"?

yeah this is like programming a game engine all over again

>>1040468

Please tell me where you get those wallpapers.

>>1040568

Maybe I am too much of an autist but I hope this is sarcasm.

>>1040553

yeah let's blame the users for shit design

by the way I've seen more command line this month than you've in your whole life

>>1040462

There's no point in talking to keyboard zealots anon. They are genuinely disabled.

>I try to move my hand to the mouse but instead my arn overshoots the desk and I fall off my chair OMG this is so slow

>my 'mouse' keeps moving when my fat palms rest on it damnit it is distracting so that's why I went full keyboard now I'm more productive than ever, 200 packages compiled today alone!

>>1040447 (OP)

NO!

there's enough niggers and women using computers already

>>1040484

>>1040487

the point is the same you can put more information in the command line unless you want a window with a book worth of error text.

it's not that hard, but I refuse

void SHOW_ERROR_FOR_NIGGER( char* NIGGER_TEXT )
{

	GtkWidget *nigger_dialog=gtk_message_dialog_new( GTK_WINDOW(parent_window), 
			flags, GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE, "%s",
			NIGGER_TEXT );

	gtk_dialog_run(GTK_DIALOG(nigger_dialog));

	gtk_widget_destroy(nigger_dialog);
}

SHOW_ERROR_FOR_NIGGER ( "YOU WILL NEVER BE WHITE" );

>>1040508

>This deflection of responsibility and criticism is so common I can't tell if you truly believe this or if you're merely pretending to.

>it's the operating systems fault that a program some random wrote doesn't provide graphical error messages

>>1040584

At least a missing library error could be enforced system-wide.

It took a decade of complaints for gnome to implement a graphical kill dialogue so users didn't have to open a virtual terminal and use ps -ax when a graphical application hangs.

The logic then follows, what would a retard who can't use a terminal want that output for anyway?

The concept of a 'desktop environment' where everything exists as a GUI purely exists for niggers, retards and women who have zero interest in fixing things and just want to call in the "nerd" (white man.)

>>1040557

>try using windows file explorer

>right click side pannel

>crashes, no error

>>1040508

Debug is literally down to implementation

>>1040585

>At least a missing library error could be enforced system-wide.

This is the job of the package manager, which is a part of distributions, not the kernel.

>Be Linugger

>Too autistic to understand ease of use or best practice design

>F-fucking normalfags, th-they just don't get it!

>Year of the Linux Desktop a-any day now!

Yes, it sucks

https://www.debian.org/women/

>>1040459

Not necessarily. Just normie users.

>>1040584

>don't provide jack shit

>be surprised when people opt to not reimplement everything in an ad hoc manner every single time

But at least it's not Linux's fault, dog bless.

>>1040615

>Christian fundamentalism

Opinion dropped

>>1040616

I expected a retarded response but I didn't expect it to be that retarded.

>>1040615

>the kernel is expected to provide an entire gui toolkit

kill yourself

you are the problem

>>1040447 (OP)

>shitty complaint thread

>>>4chan

>>1040619

I have an idea!

Let's merge GTK into SystemD and then merge SystemD into the kernel!

Year of the linux desktop inevitable!

>>1040619

The operating system should, retard. That "Linux" is a kernel together with a bunch of ducttaped components lacking any design whatsoever is the problem, not an excuse. In that sense alone, systemd actually has the right idea, but of course it's done by Rathead and Poettering, so it's an abomination.

>you can't blame the cardboard house for breaking down, it's cardboard after all

Maybe stop building shit out of cardboard then.

>>1040622

I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux.

<The "operating system" does retard, via GNU GTK.

>>1040623

>no it's fine, just use this ducttaped component

>or that other one

>or this niche one that's popular on /tech/

>oh the one I recommended has breaking changes every six months btw lol

Consider understanding what you read, rather than just matching patterns blindly.

>>1040622

>Let's merge GTK into SystemD and then merge SystemD into the kernel!

<that's not good enough

>LET'S MERGE ALL OF GNU INTO THE KERNEL, THAT WILL FIX THE PROBLEM

>>1040624

>>1040625

>>1040625

>>LET'S MERGE ALL OF GNU INTO THE KERNEL

Who are you quoting?

>>1040624

consider the ramifactions of your suggestions instead of just spewing complaints blindly

>>1040627

>>1040622

>The operating system should, retard. That "Linux" is a kernel together with a bunch of ducttaped components lacking any design whatsoever is the problem, not an excuse. In that sense alone, systemd actually has the right idea, but of course it's done by Rathead and Poettering, so it's an abomination.

the logical conclusion to your worthless blabbering is that linux should include the entire GNU operating system under one umbrella

I see no rational objections have been raised, just freetard sperging...

>>1040628

Oh no, the operating system would have an actual design instead of providing ten million crevices for vermin and ten million easily accessible opportunities to fix some minor fault. What will /tech/ circlejerk about now?

>>1040629

But not in the KERNEL you illiterate mongoloid.

>>1040629

fortunately it can't, because the majority of GNU is now under the GPLv3, and linux cannot include it unless it switches to the GPLv3, which would displease linus's cianigger and jew overlords.

>>1040631

>>1040631

>But not in the KERNEL you illiterate mongoloid.

<Instead of including the entire GNU operating system into the KERNEL, let's include the KERNEL into the entire GNU operating system.

can't because

>>1040632

linux and stallmann aren't fans of eachother.

>>1040634

Admittedly I'm not too deep into license bullshit, but I doubt that. Wouldn't BSD (not ideal but much closer to a designed system than Linux is) have run into the same problem with GCC? They seem to be doing fine.

>>1040631

The fact that all of these components are separate is a core principal. A thing should do one thing and do it well, else it will become a bloated monstrosity and do nothing well, and then you get windows 10, where disgruntled microsoft employees say the source code is such a garbage fire nobody knows what's going on anymore.

>>1040635

GCC is under a separate license specific to GCC

>The source code is distributed under the GNU General Public License version 3, with the addition under section 7 of an exception described in the “GCC Runtime Library Exception, version 3.1” as follows (or see the file COPYING.RUNTIME):

https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

>>1040635

luckily GNU has a convenient table to answer these questions

https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

The kernel is GPLv2, not LGPL

It can be mixed with only with GPLv2 and LGPLv2, not GPLv3 or LGPLv3.

>>1040640

>>1040635

consequently the other way around, if GNU wanted to include the kernel in a wider umbrella project, instead of the kernel including GNU

A derivitive work licensed under the GPLv3 cannot include works licensed under the GPLv2 "ONLY" ( this is a thing ).

The kernel is NOT GPLv2 or later, it's GPLv2 ONLY.

https://www.kernel.org/doc/html/latest/process/license-rules.html

>The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0)

which means it cannot be included in any GPLv3 derivative work.

>>1040637

They can be separate entities and still follow the same design. As a very small example that already shows how deep the mismatches run, look at how every goddamn program STILL handles command line arguments differently, even the common ones for stuff like version display and help messages. A more useful example would be a set of common data formats that ALL programs of the OS can understand and exchange, though that might already get first conflicts with the Unix nature of it all because muh files.

>GCC is under a separate license specific to GCC

Ah right, I forgot about that. It still seems kinda strange though; how can Linux distros exist if userland and kernel cannot be combined? Clearly there is some way though to be honest I'm not keen on GNU and Linux consolidating nowadays, the damage is done already.

>>1040646

> how can Linux distros exist if userland and kernel cannot be combined

there's no restrictions on them being distributed together, distribution is different from a program actually "using" a library, which is why these distros can combine all this shit together.

it's an interesting point though, is an install script "using" a library? how can an install script install and configure both GPLv2 "only" code and GPLv3 code?

It's obviously not because all distributions do exactly this. Probably because the script isn't actually using any of the software directly, it's only installing it, it never actually runs it, the user does.

>A more useful example would be a set of common data formats that ALL programs of the OS can understand and exchange

that's what the glib bloat is trying to do at the code level.

>how every goddamn program STILL handles command line arguments differently

i don't know what your talking about every program I run has the same format of positional and optional command line arguments

./program positional_1 positional_2 --optional_1 --optional_2 --optional_3 optional_3_value --optional_4

>>1040663

>>1040646

>>1040663

What does -v do for all of these? Print the version? Verbose mode? Nothing? Something completely different?

How do you print the help message? --help? -h? -help? What happens when you use the wrong one?

How many of your programs support --? Can they deal with files that start with dashes?

And these are just two extremely common cases.

>inb4 just read the manual

I know memorization makes you feel smart, it's what's so appealing about systems like these. But what you are memorizing is how to work with other people's design mistakes, not anything sensible.

>>1040669

they do whatever the fuck the developer wanted them to do?

what are you some kind of argument fascist?

>>1040669

they are all standardized

<ANSI/ISO 9899-1990

>5.1.2.2.1 Program startup

A hosted environment need not be provided, but shall conform to the following specifications if present.

"Program startup"

The function called at program startup is named main . The implementation declares no prototype for this function. It can be defined with no parameters:

int main(void) { /*...*/ }

or with two parameters (referred to here as argc and argv , though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /*...*/ }

If they are defined, the parameters to the main function shall obey the following constraints:

* The value of argc shall be nonnegative.

* argv[argc] shall be a null pointer.

* If the value of argc is greater than zero, the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup. The intent is to supply to the program information determined prior to program startup from elsewhere in the hosted environment. If the host environment is not capable of supplying strings with letters in both upper-case and lower-case, the implementation shall ensure that the strings are received in lower-case.

* If the value of argc is greater than zero, the string pointed to by argv[0] represents the program name ;argv[0][0] shall be the null character if the program name is not available from the host environment. If the value of argc is greater than one, the strings pointed to by argv[1] through argv[argc-1] represent the program parameters .

* The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination.

https://www.pdf-archive.com/2014/10/02/ansi-iso-9899-1990-1/ansi-iso-9899-1990-1.pdf

are you suggesting they create another standard around your narrow vision of what -v should mean?

>>1040678

html version

http://port70.net/~nsz/c/c89/c89-draft.html

GNU libc

https://www.gnu.org/software/libc/manual/html_node/Program-Arguments.html

(You)

>>1040556

>Please tell me where you get those wallpapers.

the internet

>>1040459

>informing the user of errors in an interactive system is a bad thing

Absolute brainlet

>>1040631

If the fact that Linux is merely a kernel and not a comprehensive system really bothers you that much then just use one of the BSDs (this is one of their own arguments for why you should use their OS). You have all the same software, just look at FreshPorts or pkgsrc.

>>1040669

If having to decide whether to use -h or --help (vast majority programs allow you to use both btw) is your biggest problem, then you should use an operating system that comes configured with a nice Fisher Price user interface so it's easier for that peanut you call a brain to handle. -h and --help exist so you know whether or not -v is for version or verbose; additionally, there are these things call man pages that would give you that answer immediately without any trial and error.

>>1040689

Very helpful. Thank you for your contribution.

>>1040714

Did you just have to vent at someone or why are you telling me things I brought up myself?

>He wants an input-blocking pop-up window to appear in front of whatever he's doing whenever something breaks

>>1040581

How many times have you seen a normalfag using a computer hover their mouse pointer around a button and then move it very slowly onto that button before clicking it?

>>1040622

>Let's just merge KDE and LibreOffice into the kernel and be done with it

Maybe macOS is more your speed, if you care so much about muh unified user experience.

>>1040799

>into the kernel

I swear to god analphabetism runs rampant on /tech/.

>>1040799

Forget normalfags I've seen keyboard memers who don't know about search in graphical file explorers.

>>1040806

You know what I mean.

>>1040817

>retarded quote of something nobody said

>hurr durr go to apple then

I legitimately don't.

>>1040818

If you're looking for an environment where a central committee decides that there should be one accepted way for the operating system to function with a level of control to the point that they dictate a GUI system and all software developers for that environment must comply to that design, you have two choices:

>try to start your own

>go to apple/microsoft

>>1040823

It could be an option you turn on or off. Stop the excuses.

>>1040899

There is an option, make it yourself. If you can't I'm sure one of the thousands of distros out there have implemented exactly what you want.

>muh repositories

>>1040508

That is pathetic. This is not even a Linux or UNIX issue, it's a matter of designing according to different models of liberty. OS intervention in some issues diminishes programs potential flexibility, and many people when designing their program will prefer to have to work an extra mile to implement some things, should their program need it, than be limited so that something that is not relevant for them can be applied universally. Other people won't, and that is why we have different OSes out there, and some of them are open source so you can adjust them to your needs if you want.

Your point is simply like saying, why should a citizen be able to do X and Y, of the government can do it for them?

And, well, we have a bunch of people who freak out if the government intervenes too strongly on their lives, while others think a lax, liberal society is flawed, undisciplined and decadent. That is why we have different ideologies and different countries on earth where you can move to so they will fit your necessities better.

So the point is quite simply, if you want to work amd get stuff done, you have many tools around you, choose what works best for you. If you prefer to just spend eternity in a loop of trying to prove your preferences are objectively better than everyone else's because it helps you kill time, or feeds your vanity, then, sure, you can do that as well.

>>1040948

<b-b-b-b-but what if people want their operating system to be shit

<checkmate UNIX haters

>>1040954

That is not an UNIX issue, as I stated. Those are simply design choices, and there is no objective beter or worse, sonce good arguments can be made for both choices, freedom or top-down control are both valuable, depensing on use-case. Just make your choice and stop winning.

>>1040954

Judging from the responses in this thread Linux fanboys actually do seem to like their OS being a mess.

Cry moar winfag. How about you run you try and run your software from the terminal and monitor errors that way?

>>1040965

>>1040973

OP here. I do use Linux and haven't Windows for 12 years except on other people's computers. Doesn't mean I can't notice the flaws because I'm not a damn fanboy / freetard. Sure I can run everything from the terminal - doesn't mean that it's optimal!

>>1040447 (OP)

You probably don't want to dump standard error (not standard output like every unix illiterate keeps saying) to dialog boxes - they are verbose debugging messages, and would essentially be graphical spam if you had to okay each one.

You probably want a concise single description of why the software failed - the vast majority of the time, that falls on the developer of the software to do and there are different ways to do it. Textmode software shouldn't be linked with GUI libraries and should give textmode errors. GUI software could give dialog boxes , and sometimes does, or could write some kind of log. Right now, many applications, across EVERY SINGLE PLATFORM, don't have good error handling. A huge portion of my job in IT is figuring out why windows apps crash without leaving any kind of user visible error. Unfortunately, Windows Applications generally don't have verbose standard error like linux apps, and there error messages are far more cryptic - often only undocumented numbers for most proprietary software.

When it isn't the applications fault, (IE. wrong binary format, missing libraries , ...) you could have graphical launcher your using provide error messages.

If these are features you want, you can implement them, or request them. Go file bug reports or review and add the code yourself.

Error handling sucks everywhere unfortunately, but I use linux for the freedom, not error handling superiority - which I'd still say it has anyway.

>>1041002

Yeah, dumping the whole terminal inside a dialog box obviously isn't smart. But SOMETHING has to be fucking done.

>>1040557

>>Trying to use windows file explorer content search option

>>Searches for a while and then closes the window

>>Check event log

>>Error id 1000, file explorer has crashed.

Final solution to Downdowsers and NPClosers who literally believe the quality of GUI programs is any better than laughably bad.

>>1041039

If you think there is a problem, write an application monitor for your launcher - for bash its as simple as returning keeping the exit code of the program in the prompt. For a graphical environment you could write a complex loader that uses waitpid(), and monitors stderror, and dmesg. Or, use software that doesn't suck. If the error handling on your program is unacceptable fix it , or file a bug report with the project. Unlike quickbooks, you have a voice in the development of open source software.

From my perspective, it hasn't been worth it. I am normally not intrested in debug output of my graphical programs, and if I am, I will run in terminal. 99.9.. % of the time they just work. The one time they don't I will open terminal and observe the problem. If its worth it to you , things can be done.

As a heads up , some linux distributions like Fedora do have mechanisms to detect and report segfaults graphically (were an application would be unable to do its own error handling) - I emphatically do not want this "SEND | DONT SEND" functionality on my computer.

>>1040616

top fedora

>>1040620

this.

OP is a lazy and a faggot at that.

>>1040635

but aren't most *BSD people fans of LLVM/Clang because of the license?

>>1041046

>From my perspective, it hasn't been worth it. I am normally not intrested in debug output of my graphical programs, and if I am, I will run in terminal. 99.9.. % of the time they just work. The one time they don't I will open terminal and observe the problem. If its worth it to you , things can be done.

Also, let me mention that terminal output often isn't very useful. In fact sometimes it can misdirect you. So dialog boxes with actual information would be great.

>If the error handling on your program is unacceptable fix it , or file a bug report with the project. Unlike quickbooks, you have a voice in the development of open source software.

If I tried to do that for all the software I use I'd have no time to take a shit. Devs should take care of their own turf.

>>1041058

They still used (or still use?) GCC for a long time.

>>1041060

Well fuck the world i guess man. Your not willing to file a bug report or fix yourself, your not willing to use better software. Everyone sucks as a dev, but your better, you just don't want to do anything about it. You'd rather complain about it on 8ch. Got it.

>>1041068

Hey, it's a discussion thread. I do file bug reports sometimes but I'm not the world police. And I don't dev so I get that it's hard work. But they can be criticized! Especially if Linux aspires to be a Windows replacement.

OP, Linux will never be good because it's based on the Unix philosophy, a retarded way to think of modern end-user computing.

Focus your energy on Haiku, ReactOS or any other alternative OS. At least those have the potential of becoming good some day.

>>1040447 (OP)

Set up a terminal in the corner of your screen and pipe STDERR there. Problem solved, faggot.

The fundamental problem is in how UNIX handles errors. In UNIX, an error message is dumped onto stderr as text. There are huge problems with this approach. The first one is that there is no way to correct the error, so the program usually terminates or does something you don't want. The second one (which is pervasive throughout UNIX) is that error messages are not allowed to change because idiots "grep" for text instead of checking for error codes (usually because there aren't any). That leads to other problems like not being allowed to improve (or localize) error messages, so UNIX says bullshit like "not a typewriter" instead of something that actually makes sense. This mentality of having programs parse and interpret text meant for humans is one of the core reasons UNIX and pipes suck.

Instead of this brain damaged bullshit, some languages like PL/I and Common Lisp have a error handling mechanism called conditions. Instead of unwinding the stack (or worse, killing the program), the handler gives you the opportunity to fix the problem and try again. This works for out of memory and end of file too, and it's mostly transparent to the program. When there is an unhandled condition, it runs an outermost handler set up by the OS or language runtime while keeping the original context that caused the error, which can display an error message, log the error, enter a debugger, or signal it to the user in the most appropriate way for the user's UI. What makes this powerful is that Lisps and some mainframe operating systems use this same system for all errors, including compiler errors and warnings and I/O errors.

The  programmers  at  BBN  were  generally  the  exception.  Most  Unix  pro-
grammers  don’t  fix  bugs:  most  don’t  have  source  code.  Those  with  the
code  know  that  fixing  bugs  won’t  help.  That’s  why  when  most  Unix  pro-
grammers encounter a bug, they simply program around it. 

It’s a sad state of affairs: if one is going to solve a problem, why not solve
it once and for all instead of for a single case that will have to repeated for
each  new  program  ad  infinitum?  Perhaps  early  Unix  programmers  were
closet  metaphysicians  that  believed  in  Nietzche’s  doctrine  of  Eternal
Recurrence.

There are two schools of debugging thought. One is the “debugger as phy-
sician”  school,  which  was  popularized  in  early  ITS  and  Lisp  systems.  In
these environments, the debugger is always present in the running program
and  when  the  program  crashes,  the  debugger/physician  can  diagnose  the
problem and make the program well again.

Unix follows the older “debugging as autopsy” model. In Unix, a broken
program dies, leaving a core file, that is like a dead body in more ways than
one. A Unix debugger then comes along and determines the cause of death.
Interestingly  enough,  Unix  programs  tend  to  die  from  curable  diseases,
accidents, and negligence, just as people do.

Fun fact: You can actually make your DE print GUI messages when an app fails. Just make its launcher launch every app in a way that it pipes its stderr to zenity. That's all. And you can do it in a single line of bash.

>>1040447 (OP)

Why the fuck do you want that you retard? I bet you use Reddit and Facebook.

>>1041384

>OP asks why Unix programs don't display graphical errors by default

>The fundamental problem is...

>proceed to ramble about unrelated error handling shit and forget OP's question entirely

Someone's getting senile.

>>1041446

>how error handling is done on the OS is unrelated to how error handling is done by programmers

Someone's getting senile alright.

>>1041474

OP asked why Unix doesn't display error messages in dialogue boxes, which it can (see >>1041437 ). This has nothing to do with the Unix hater's bitching about Unix not using error codes or conditions, which aren't inherently friendlier to dialogue boxes than the current solution.

Personally, like >>1041002 says I prefer having verbose debugging messages in the terminal to short popups or questionably helpful error codes. Conditions sound neat so I guess that's another excuse to fuck around with Common Lisp.

The Windows way of doing it is really fucked. I prefer semi-verbose terminal error messages instead of the usual "error codes". I get why they might exist, but having that as the sole output is one of the worse things that's happened to design. I'm with >>1041479 on this one. It doesn't promote troubleshooting or provide any advice, even in a brief form. It just promotes the "Jewgle the error code" mentality, where you're solely reliant on big daddy microsoft to solve your problem. No free thought, just copypaste the pretty numbers, goy!

>>1041479

>conditions, which aren't inherently friendlier to dialogue boxes than the current solution.

>Conditions sound neat

They are neat, but more importantly, why are you declaring shit about things you admittedly haven't used?

>>1041486

>what's wrong with authoritatively speaking on things you admit you have no idea about

I realize I'm on /tech/, but holy fucking shit this has to be a troll question.

Though I suppose compared to the other idiots on this board you are at least honest about it.

>>1041488 (nice Hitler digits)

>what's wrong with authoritatively speaking on things you admit you have no idea about

I can make an educated guess based off his description, faggot. The rest of his post wasn't relevant to OP's specific complaint and neither was his description of conditions, so it was a fairly safe assumption.

Could you have error dialogue boxes with conditions? From what he's described, sure, but the same goes for every other technique he mentioned in his soapbox post, including the ones he doesn't like.

>>1041446

This. When you have a programmer at your terminal, and an interpreted language, dumping the user to terminal to fix the problem is possible. When you have a real systems language and a normal user at the terminal, debugging isn't a benefit - a error message explaining what library is missing, or etc is far more helpful than dumping the user at a debugger because open returned ENOENT. As far as error handling for a user goes, dumping to a debugger is actually far more confusing than no error message or CLI only error messages.

>>1041486

Plain text is actually a cool idea and everything as a flat file was a revolution idea, and when taken further in 9P resulted in being able to create VPNs with standard unix tools like ln . Everything as a file is actually an interested idea that has real world trade offs including machine parseability and standardized interfaces vs human readability , debuging, and composability

People have suggested using XML, or JSON as replacements to plain text but so far XML has sucked.

Obviously in the real world there are trade offs. But everything as a file and plaintext have resulted in a usable, flexible, and interesting operating system. I am open to alternatives. So far The Unix Way has been awesome and incredibly productive.

>>1041525

The Unix Way is good. It's a shame it doesn't typically get applied to the kernel though. Perhaps something like >>1041235 >>1041246 >>1041278 will change that.

>>1041384

This is actually a good point. Usually I've always thought debugging was only after programs had shitted out, since when a program fucks up its naturally assumed you terminate afterwards. How do you fix problems in an already running program? Especially when that program is compiled?

>>1041525

>everything is a file

lol

>the unix way

lmao

>>1041532

You redefine the offending parts at runtime and retry the failed section. From what point you can reasonably retry depends on the program, obviously.

>Especially when that program is compiled?

Think of compilation as a cache. Alternatively/Additionally, you can have the compiler available at runtime. The latter is extremely common in Lisps because despite the initial barf reflex (which likely comes from the utter uselessness of (this construction in) other languages) the compiler is very useful to have around.

>>1041479

>error codes or conditions, which aren't inherently friendlier to dialogue boxes than the current solution

Of course they're friendlier to dialog boxes because the OS knows what the error is, how to present it, and can actually give the user a chance to control what happens. The UNIX way dumps some text on stderr, if you're lucky. Conditions produce a standard mechanism for error handling and recovery. Common Lisp gives you a list of actions you can take (restarts) and the OS could show that graphically and if it's a file name it could open a file chooser dialog box, or if it's a wrong string it could give a text box to edit it. The nice thing is that this separates the cause of the error from handling it, so anyone can do this. You don't have to wait for the OS. It's like the difference between a debugger and UNIX's printf "debugging" (which was never good because even in the 60s you could set breakpoints and print the values of variables).

>>1041525

>Plain text is actually a cool idea and everything as a flat file was a revolution idea

Computers had plain text and flat files long before UNIX and used text for configuration too. Even the so-called "revolutionary" idea of UNIX, getting rid of any files that weren't sequences of bytes, was just a limitation of some other minicomputer operating systems of the era. The only difference is that the shills claimed that the OS not doing as much and making everyone reinvent wheels was a good thing, just like they did with the lack of dynamic linking and the other huge flaws. Most of the "genius" of UNIX was being able to shill an inferior version of what computers already did to people who never used computers (or only used DOS or CP/M and believed it when weenies blamed UNIX flaws on multitasking, multiuser, or virtual memory).

>People have suggested using XML, or JSON as replacements to plain text but so far XML has sucked.

This is your brain on UNIX. XML and JSON are plain text.

>I am open to alternatives. So far The Unix Way has been awesome and incredibly productive.

UNIX wastes an enormous amount of time on parsing and piping text from one program to another. On a better OS, none of that would even exist. Your idea of productive is wasting time on bullshit that shouldn't be necessary.

    No, no, no, you don't understand the elegant simplicity
    of Unix error mes- sages.  Remember: The map is not the
    territory.  No translation is ever completely accurate.
    The text doesn't MEAN anything, it simply IS.

    A truely elegant Unix would eschew the use of
    English-like phrases in its error messages - they just
    confuse the issue.  If your error message had been
    just, say, "+2C)", you would have been equally
    enlightened, and could have grep'ed just as easily -
    but much more quickly.

Gee, I thought the politically correct error message was
just the same as the success message: null.  Think of the
advantages.  No pesky man page to update, or have users
complain about.  When it gets piped into the middle of you
text file, your file no longer has "%%swap space exhaused"
spliced into it.  It does make it a tad more difficult to
grep for the error in the sources, but hey, that's a small
price to pay for making the elegant pipe mechanisms robust
and bullet-proof.

>>1041803

>Of course they're friendlier to dialog boxes because the OS knows what the error is, how to present it, and can actually give the user a chance to control what happens

But does the OS need to know what the error is? Does it really have to check an error code against some internal list of known errors just to display a fucking dialogue box? It's not like the application can directly spit out text to a standard location or anything.

Conditions make some sense if you can send the user to a debugger. Error codes, on the other hand, are "here's a file picker!" babby mode at best and outright inferior to stderror plaintext at worst.

>>1041821

He's talking about the character encoding, not the markup language.

>>1041825

Except literally nobody was talking about character encodings here. He's the one that brought it up and intentionally misread the conversation in order to get his big 'Unixtards BTFO' moment, despite the fact that it doesn't actually hold up when you think about it for 2 seconds.

>>1041821

>XML and JSON are not plain text

They are text though, which is the point he was trying to hammer. The problem is that if you are working with XML or JSON you have to constantly serialize and deserialize your data when communicating with other programs. Instead you should be able to just pass the data directly skipping this double serialization phase.

>>1041486

>So if someone describes a fetish or sex act to me, I can't call it shit unless I try it myself?

Don't knock it till you try it.

>>1041864

What do you expect to do with plaintext... not parse it? not spit it out in a consistent format?

Deserializing is just reading it, serialization is just putting it out. Do you really believe that wc -l | grep | process.sh is just directly moving the data..? How do you think each program manages to spit out different formats?

There's no such thing as "passing the data directly"; all program interop requires some kind of de/serialization format; plaintext is just one of those (and it's only notable aspects are that its not well-defined, and it's sometimes more readable). UNIX tooling is only special in that, since the format is extremely underspecified, it comes with a lot of tools for massaging the data into a more manageable format (and the core tooling tend to be more maleable/less dependent on specific format requirements, eg grep and wc are only reliant on newlines/EOF).

The issue with XML is that your data transmission ends up being 10X the size of the data itself, and JSON is more resource-friendly... but has a weak specification (eg lacking many useful types, and even has ambiguities), and only enforces the syntax but nothing for the schema.

>>1042175

>What do you expect to do with plaintext... not parse it?

Duh. Consider this broken JSON parser from i3blocks:

void json_parse(const char *json, const char *name, int *start, int *len){
	char *here = strstr(json, name);
	*start = *len = 0;
	if (!here) return;
	here += strlen(name) + 2;
	*start = here - json;
	if (*here == '"') { /* string */
		here++;
		while (*here++ != '"')
			*len += 1;
	} else /* number */
		while (isdigit(*here++)) *len += 1;
}

https://github.com/vivien/i3blocks/blob/9e8e313d252e5000d6bebb59fbaaff506bcb0408/json.c#L106

it's better now, don't worry

For plaintext parsing, something to this effect would be perfectly valid. For JSON it's fucking retarded.

>>1042175

The entire point of the unix way etc. being a joke is that you would never ever write a program where each function parsed text, turned it into some data structure and then turned that back into text for the next function.

Can you even imagine how dumb that would be?

:( Something Happened

>>1041821

XML literally is plain text designed to be written with an ordinary keyboard. Saying it's not easy to read doesn't make it not plain text. It was actually meant to be a format for documents in the vein of SGML, but UNIX weenies promoted it as a replacement for binary data storage because they want everything to be plain text.

https://en.wikipedia.org/wiki/XML

>Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. The W3C's XML 1.0 Specification[2] and several other related specifications[3]---all of them free open standards—define XML.[4]

>>1041825

>But does the OS need to know what the error is? Does it really have to check an error code against some internal list of known errors just to display a fucking dialogue box?

It gets that information from restarts provided by the program. This explains how it works.

https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node315.html

>It's not like the application can directly spit out text to a standard location or anything.

You can do that in Lisp too, but that's the "debugging as autopsy" mindset. Many times an error can be corrected by a caller and is never even seen by the user. That's the whole point of having scoped condition handlers. Printing text doesn't do the same thing at all. If you used assembly and interrupt handlers, you would understand conditions right away, but the new generation of UNIX weenies is being taught C as the "low level" language and have trouble understanding them. UNIX brain damage not only leads to vastly inferior software, it also makes fundamental computing principles harder to understand.

>Error codes, on the other hand, are "here's a file picker!" babby mode at best and outright inferior to stderror plaintext at worst.

How is the ability to correct an error and continue "outright inferior" to dumping text on a virtual printer or tape drive? Dumping text doesn't fix anything.

>>1042175

>What do you expect to do with plaintext... not parse it? not spit it out in a consistent format?

Why are you so focused on parsing text. Text is for people to read. If GUIs worked the same way as text on UNIX, you would be OCRing screenshots so you can control a program that moves the mouse with a virtual mouse driver.

>Do you really believe that wc -l | grep | process.sh is just directly moving the data..? How do you think each program manages to spit out different formats?

Pipes are UNIX brain damage and a shitty and tremendously inefficient way to do IPC. What really sucks is that shell scripts probably have 1000% overhead or more in context switching, forking (a really slow and stupid way to start processes), and parsing and printing text, but weenies refuse to check array bounds because it's "too slow." Shell scripts make Python and Perl look fast.

>There's no such thing as "passing the data directly"; all program interop requires some kind of de/serialization format;

That's factually wrong. Again, UNIX wastes an enormous amount of time on parsing and piping text from one program to another. On a better OS, none of that would even exist.

https://multicians.org/multics-vm.html

>The fundamental advantage of direct addressability is that information copying is no longer mandatory. Since all instructions and data items in the system are processor-addressable, duplication of procedures and data is unnecessary. This means, for example, that core images of programs need not be prepared by loading and binding together copies of procedures before execution; instead, the original procedures may be used directly in a computation. Also, partial copies of data files need not be read, via requests to an I/O system, into core buffers for subsequent use and then returned, by means of another I/O request, to their original locations; instead the central processor executing a computation can directly address just those required data items in the original version of the file. This kind of access to information promises a very attractive reduction in program complexity for the programmer.

>UNIX tooling is only special in that, since the format is extremely underspecified

That used to be considered a bad thing. When you use "ls" the computer has no way of knowing what a file name is or that these characters are a number that makes up a file size.

>>1042221

That's the essence of why UNIX sucks.

> Yep, Unix can sure handle text. It can also handle
> text. Oh, by the way, did I mention that Unix is good at
> handling text.


Text ... text ... oh yeah ... you mean VI, right?

>>1042447

>How is the ability to correct an error and continue "outright inferior" to dumping text on a virtual printer or tape drive? Dumping text doesn't fix anything.

>missing the "at worst" part

Take a look at Windows' absolutely brain-dead, worst of both worlds approach to error codes sometime. The faggots thought sending error codes not to the OS, but to the user was a brilliant idea, so instead of getting what could be a stderror-style message you have to search a random jumble of letters and numbers on the internet and hope there's some decent documentation on this shit. When you bring up error codes, most people will assume you're talking about this faggotry (which you'll no doubt blame on Unix too) and dismiss your post altogether.

>>1040447 (OP)

Why?

>>1040465

That IS what happens on Linux.

GUI on Linux is mostly a hack, not really meant to be there

>>1042482

Tell that to all the *buntu users...

>>1042482

>GUI on DOS is mostly a hack and not meant to be there

>GUI on *BSD is mostly a hack and not meant to be there

>GUI on NT is mostly a hack and not meant to be there

1. Use strace

2. Find GitHub of your software package, and berrate them for not including error messages, and include your strace log

3. Kill yourself

>>1042453

>windows did X badly so X is shit

Literally half of this thread. Are you people really this retarded or are you merely pretending?

>>1042482

<eyes on animals are mostly a hack, not really meant to be there