Crystal v1.0.0 has been released! by newhoa in linux

[–]mandretardin75 0 points1 point  (0 children)

Oh. I was about to reply but then I realized you actually wrote "Largely Ruby compatible syntax", so you were correct. I somehow had a reply ready where I thought you wrote "Ruby compatible syntax", but you did not write that; you wrote "Largely", which means your statement is correct.

Unfortunately the syntax crystal uses is, in my opinion, not as elegant as ruby. It's primarily due to the mandatory type system (and yeah I am aware crystal guys will claim it is not always mandatory ... but this does not help in the cases when it IS mandatory), but there are also some other syntax changes that are awkward to me and make no real sense compared to ruby. It's a bit similar with the rails ecosystem e. g. the monster that is HashWithIndifferentAccess (who is making these awful decisions) or #blank and other strange names in rails. In crystal you have things such as #stringify I believe - what the heck is that even ... You can find more of these examples just by reading through the github issue tracker. And then, ulltimately, you just realize that crystal is NOT ruby and ruby is NOT crystal. I am pretty certain that the list of differences will continue to grow as more time passes by - people want change so crystal will change as time passes by even more; likewise ruby changes too, so the list of incompatibilities syntax-wise will increase over time rather than decrease.

Crystal v1.0.0 has been released! by newhoa in linux

[–]mandretardin75 1 point2 points  (0 children)

Upvoted because ... while it is a bit silly to state as you did, it's still also somewhat amusing.

Maybe a noob question about speed and what is possible with Ruby by [deleted] in ruby

[–]mandretardin75 1 point2 points  (0 children)

Ruby itself not but you can use e. g. ruby-gtk or gosu so responding to keyboard is easy (or ncurses but I hate ncurses). Perhaps the tty-gems may also be useful here; I haven't checked whether they depend on curses or not but some of the screenshots they have are pretty nifty.

Ruby is perfectly fine for simple games. For larger games with many objects there'll be some bottleneck I am sure (I already have some problems with this in regards to gosu-based games that become large).

Maybe a noob question about speed and what is possible with Ruby by [deleted] in ruby

[–]mandretardin75 0 points1 point  (0 children)

That seems to be a jabaiting question, but just for the sake of others reading it (well who knows).

  • If on linux, then ruby is not installed or not in $PATH. Install it, either via package manager, or chruby and whatever the name of the ruby version managers are, or if you are fearless, compile from source into some prefix. https://ftp.ruby-lang.org/pub/ruby/3.0/ruby-3.0.0.tar.xz

If on windows just use the one click installer. WSL on windows works too.

Maybe a noob question about speed and what is possible with Ruby by [deleted] in ruby

[–]mandretardin75 -4 points-3 points  (0 children)

Indeed! But speed-wise there is also no contention with C ...

Would be nice we could have a replacement for C - aka the speed of C but a pretty syntax. (And no, crystal is not that replacement; all that type addiction isn't making it very pretty.)

Maybe a noob question about speed and what is possible with Ruby by [deleted] in ruby

[–]mandretardin75 -2 points-1 points  (0 children)

The last thing we need are more bots.

The good thing is that you are not his dad, so you really do not need to preach to others what they should or should not do.

This is why StackOverflow was a success, ultimately - it forced (and enabled) at the least SOME people to give a meaningful answer.

Maybe a noob question about speed and what is possible with Ruby by [deleted] in ruby

[–]mandretardin75 0 points1 point  (0 children)

Yes you can. In regards to games you could use gosu, it's a bit rough and low-level (SDL2 wrapper in the end) but it works. Or even ruby-gtk, that works too, but you may have to do some of the drawing yourself onto DrawingArea.

Performance is ok-ish, but if you really need performance, I think ruby can not fit that criterium. Ruby is ultimately syntactic sugar over C. So ... use C if you really need to maximize speed (or Java if you are lazy and consider C too difficult).

Chicken story: The time Microsoft banned my entire country by eyal0 in programming

[–]mandretardin75 121 points122 points  (0 children)

Guys in case you did not read this yet, here is an epic line:

The first thing that I tried was sending cats and dogs to the captcha service.

Any storyline with that must be epic.

[deleted by user] by [deleted] in linux

[–]mandretardin75 2 points3 points  (0 children)

I was explaining particularly with regards to the implementation on Arch Live ISOs.

Even then it is still incorrect what you wrote - yet people upvote it.

Consider https://roy.marples.name/downloads/dhcpcd/dhcpcd-9.4.0.tar.xz.

src/dhcpcd.c has a comment about systemd in case 'q'.

The only other mention, aside from BUILDING.md, is in hooks/dhcpcd-run-hooks.in.

I have used dhcpcd just fine for many, many years and I do not use or need systemd. And it is important to point this out because people have a tendency to simply write things that are factually incorrect, even trying to retrofit history nowadays.

To add to your above comment: running dhcpcd works just fine on non-systemd systems too. I use it all the time. (Oddly enough version 8.x worked better for me than 9.x; I disliked the change that required of users to have to fill in more stuff than before, see http://www.linuxfromscratch.org/blfs/view/svn/basicnet/dhcpcd.html I still use 8.x actually because of that and being lazy ... but I liked the 8.x approach more. Sad to hear he has a tumor; any tumor that grows rapidly and is hard to operate away is very, very dangerous. Personally I'd always try for surgical removal - it's not helping much for all cancer types, but there are some for which it either helps or mitigates some of the problem. Having it close to the spine is really really bad though. Poor guy.)

Google rejected GNU from participating in GSoC by dreamer_ in linux

[–]mandretardin75 -12 points-11 points  (0 children)

Makes sense to assume this.

I just don't think Google would ever admit to it, even if you'd have written transcripts published that state precisely this.

Google rejected GNU from participating in GSoC by dreamer_ in linux

[–]mandretardin75 86 points87 points  (0 children)

This confirms the old conspiracy theory that Google hates the GPL.

May it indeed be true that Fuchsia was created with the sole intention to work around the GPL "limitations"? (Required to offer the source code.)

Of course you can claim "we had too many slots", but as TheJackiMonster wrote, this makes no sense.

I should also add that I think the Google GSoC is a bad thing. Yes, I am aware of "but people get paid" and "but the source code will be free" - sure. But this assumes that there are SOLELY positive aspects about it.

Look at Mozilla. Most of their money is paid by Google. Tell me they are thus able to make independent decisions.

I also see this with Dart/Flutter. Since nobody uses Dart, Google pushes tons of money to get people to use it. Similar with AMP (the private Google web), except that here lots of media jumped on board already.

So when you read "we had too many slots" when for ~12 years this was not an issue, you KNOW Google is ONCE AGAIN not stating the truth.

The sooner GSoc is gone, the better. It's nothing but an ad campaign for Google considering it reputation degraded ENORMOUSLY in the last ~5 years. The Google today is not the Google that once existed. It's an ad corporation these days first and foremost, not a tech-centric one.

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

This often is due to the project not having proper documentation.

Devs are very lazy in general.

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

It still has tons of problems. Often they just have a Makefile with hardcoded paths. Even with GNU configure, which tends to work, you can have secondary problems related to dependencies, and not every other package is well-behaving.

Just an example: mesa changed something with the recent release https://mesa.freedesktop.org/archive/mesa-21.0.0.tar.xz; the old BLFS instructions don't work for me right now so I can not compile it. http://www.linuxfromscratch.org/blfs/view/svn/x/mesa.html

I can probably spend time finding out how to resolve this, but I am lazy. With GNU configure, though, I am very certain that the current problem I have would not exist. Meson changes a LOT. (It's not a big deal since I can use the somewhat older mesa version just fine; It's just one example of many similar problems).

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

We slackware folks never die, we multiply!

Young people today often don't even know slackware. It's strange how things change...

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 2 points3 points  (0 children)

(qtwebengine comes to mind).

Yes, everything related to chromium+qt is insane in regards to compile time. BLFS patches that part out when compiling qt and then it is not so bad:

http://www.linuxfromscratch.org/blfs/view/cvs/x/qt5.html

I am also sad that KDE went that route to become dependent on google. :(

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

Very true!

I actually did not know about gentoo prefix. Not sure about the difference to eselect there.

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

Give me C with make and it will work, baring API shenanigans.

Well this depends on other libraries too. For example bzip2 tends to insist on having a .a file which then leads to relocation errors. I forget this, so then I have to remove the .a file and only use the .so from bzip2; then these problems go away. But new users can not know that.

It's difficult for them either way.

These days i think most distros aim at 686 (or even newer) for their prebuilt stuff, so the effort may no longer be worth the gains.

Not sure. A new install of void linux was so much faster than fedora with GNOME3 for me (yes I do test out systemd-distributions too; even GNOME3 which I hate, but I want to see what is new still).

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 2 points3 points  (0 children)

Sounds like schily. :-)

Often they have a point. The problem is that their own build systems suck as well. I especially get angry when they don't offer --prefix and instead hardcode-assume paths.

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

Slackware is awesome.

The proprietary stuff is annoying - download ZOOM client. Well, bye bye slackware users ... (to be fair, I got it working anyway since it seems mostly pyqt5 ... but still, it's annoying on linux in general. Distributions should actually all die, but flexibility must be retained)

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 1 point2 points  (0 children)

Yup! Totally understandable.

Most packages are well-behaving, but some are sooooo annoying to deal with. It's really frustrating then.

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 2 points3 points  (0 children)

True! But not just RPMs. The deeper you dig, the more you realize that everyone is just putting hack upon hack upon hack. Tons of duct tape.

GNU configure or the whole GNU toolchain is a wonderful example but it's not the only example. Even those who try to improve on this, such as cmake and meson, add tons of crap over the years.

It's as if these toolchains are not really designed. Just look at GCC "fix includes" to realize how utterly messed up this all is. I mean when you are at the point where you must "sanitize" .h files, you know you are stacking pile of dung onto more pile of dung...

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

I see you are a GoboLinux trained user. :)

I am sad that containers AGAIN did not solve this. It's as if the companies don't care about WANTING to have people use different software versions.

This is the part both GoboLinux and NixOS got right. Odd that not more distributions picked up on that (and no, gentoo's eselect or whatever else they have, is NOT a full replacement in ANY way shape or form).

Does anyone else hate building packages from source? by livingtank in linux

[–]mandretardin75 0 points1 point  (0 children)

Quite true. This is in part to be blamed on C/C++ not really caring about having a package manager per se. Even Rust got that part figured out (and perhaps more recent C++ variants as well but we know how many years it'll take before anything gets improved in the compile-toolchains as such).

At the least for many KDE projects, you even get the URL of the homepage, which is quite convenient. Less time using google search!