INeedMana @ INeedMana @lemmy.world

Posts

7

Comments

411

Joined

2 yr. ago

Maybe obsidian? It's not open source, unfortunately, but

• works offline
• has android and linux clients
• the files are markdown, so you don't even need to export these
• the clients render the files so it can look better than plain txt files

Even PP is not safe. And squishy platic bottles too

Millennials fretting about their financial future can take comfort in knowing they are on track to retire in a better financial position than they probably think.

A lot of things were supposed to be better than we thought in the beginning

If I write my whole application/library in C, user interaction is part of the application nonetheless

That's my point. Human facing interface needs a lot of code that does not really do much, only needs to be there to cover all the edge cases of mixed parameters, cancel buttons, trying to click "next" without filling important textbox... And writing all this in C (I mean the actual user-end program interface, not the general GUI library, like GTK for example) only makes it worse to debug and maintain. You most often don't get any gain from manual memory management. If an operation is taking too long maybe it's time to put it inside the backend library. But if you're optimizing that operation you've already moved away from comparing strings inside - it's the first one to go when a loop takes too long. And once we are speaking about more than one program that we want to have consistent behavior across that might need to change in the future - C is only slowing you down.
Do you really need to reference the "Cancel" button via pointer when checking if the user should be allowed to go back?

Write a general backend library for your important stuff and optimizations in C, so you can easily load it in other languages. And then use something higher level for the interpreter/GUI where sanitizing user input is 5 lines of different libraries from the language (I mean like re or zip in Python - these are not external, these are Python's STL), instead of 50 lines of juggling pointers, which in C you would be doing even if the input was all ints.

You don't care about stack height and jumping to previous frame after being in a procedure (assembler level of looking at the code) - that's what C does for you
So why care about the pointers and structs when resizing a GUI? - Let some higher level language manage that for you

But this is high level. You shouldn't rely on strings or user input down in the mission critical part of the program

arrays (which are also not a thing in asm where you only operate on pointers)

I'm afraid that's wrong. Arrays are definitely an asm thing. An array is just a pointer to the first object of consecutively stored objects. You add n*size_of_stored_type to the pointer and you get the nth object

They are mission critical

Do you have an example? I know that many products abandon having control over what is executed because that's cheaper money/developer-time wise and leverage the power of CPU. So instead of securely comparing a string once and then using enum(int) in further code, use string comparison all the time. But that's a design problem, not technical one

Without system/external libraries C is more like easier to read assembly, without much on top of it. There are no strings as we understand them in assembly, only pointers to sequential lump of RAM where NULL character means end of string. That's why C is so great as language for libraries at the level where strings are only for debugging and a waste of computing time anyway.
But for some reason often instead of writing a library in C and then linking to it in some high level language to handle the operations where strings are common, people try to use the hammer for everything and end up with overflowing buffers or trying to make exceptions in the kernel for D-Bus

After reading the title, I did not expect this to get even more fucked up

Miranda-Jara was initially in a relationship with the girl's mother but when things soured between the two, mom allowed Miranda-Jara to move on to her then-12-year-old daughter. Eventually, they would begin living together as a couple

Oh. That sucks. "Previous" fighting games don't have people that stayed?

When I was finally playing Dark Souls 2, I was surprised that finding someone to play with was not hard. Fighting games scene might be different, though

As language-wide change: this will require additional checks, the first thing embedded developers will ask is "how do we disable it?"
For personal growth: yeah, it's a nice project :)
For production code: why reinvent the wheel? GLib is LGPL

Why? What's up with fighting games?

From what I learned at university:
CISC instruction set (x86) was developed to adress the technical reality of its time - time costly CPU operation and fast read from storage. Not long after that the situation has changed - storage reads became slower in comparison to computing time (putting it simply it's faster to read an archive and unpack it than to read unpacked thing). But in the meantime the PC boom has happened. In a way backward compatibility and market inertia locked us with instruction set that is not the best optimised for our tech, despite the fact that RISC (for example ARM) was conceived earlier.

In a way software (compilers and interpreters too) is like a muscle. The more/wider it's used, the better it becomes. You can be writing in python but if your interpreter has some missed optimization opportunities, your code will be running faster on architecture with a better optimized interpreter available.

From personal observations:
The biggest cost of software is not to write something super efficient. It's maintainability (readability and debugging), ease of use (onboarding/training time) and versatility ("let's add the feature that is missing to what we have, instead of reinventing the wheel and maintaining two toolsets").

The new languages are not created because they can do something faster than assembler (they can't, btw). If assembly code is written as optimal as possible, high level languages can at best be as fast. Writing such assembly is a problem behind the keyboard, not a technical limitation. The only thing high-level languages do better is how much time it takes a human to work with it.
I would not be surprised to learn that bigger part of these big bucks you mention go not into optimization but rather into "how can we work around that difference so the high-level interface stays the same as for more widely used x86?"

In the end it all boils down to machine code - it's the only thing that really exists when it comes to executing code. If your "human to bits translator" produces unoptimized binaries, it doesn't matter how high-level your code was written in.
And sometime in the meantime we've arrived at a level when even a few behemoths like Google or Microsoft throwing money into research (not that I believe they are doing so when it comes to optimization) is enough.
It's the field use that from time to time provides a use-case that helps finding edge-case where optimization can be made.
To purposefully find it? Dumping your datacenter in liquid nitrogen might be cheaper and probably more predictable.

So yeah, I mostly agree with him.
Maybe the times have changed a little, the thing that gave RISCs the most kick were smartphones, then one board computers, so not long ago. The improvements are always bigger at the beginning.
But the fact that some companies are trying to get RISC back into userland in my opinion means that the computer world has only started to heal itself after the effects of PC boom. There's around 20 year difference where x86 was the main thing and RISC was a niche

Could be, I did not dig that deep ;)

I don't use it but I have a colleague at work that swears by byobu

As to how, did you have your Chrome up to date?

I don't know. In the description I only see

I am tech savvy so you don’t have to disregard the details much about it. I know programming.

That is hardly domain knowledge. One would have to be writing in assembler or programming microcontrollers to be able to say they are nibbling on the domain knowledge for this. And knowing the trends we are probably not even speaking about C/C++, rather python. This makes the answering easier only because you don't have to explain what the executive is

The answers given are good and it was rather other commenters that started requesting more depth

Why? The fact that it's thousands of lines of code does not mean you can't ELI5 it

I don't think that's a solution, unless one of these installs out of the box some other version of a driver or module. And all three are rather using older versions. Maybe Mint could be a little bit more up to date.

I would propose: execute steam with PRESSURE_VESSEL_SHELL=instead (PRESSURE_VESSEL_SHELL=instead steam in a terminal or launcher where you type what to execute) and once you have xterm run the game with "$@" > $HOME/tmp/sniper.log 2>&1. That will redirect the output from the process to the file which you can use after reboot to search what is the problem you are having. If there's not much inside, retry with export WINEDEBUG=+all; "$@" > > $HOME/tmp/sniper.log 2>&1. The latter will run very, very slowly but should print debug of everything that happens in proton

From what I can find it seems that it is only available on Steam. And a lot were able to run it without problems

So they made notes on Facebook. IMO it would be already dead if not for Messenger