You are not logged in.
https://devuan.org/ui/img/devuan-emblem.svg
You can export it as png file in Inkscape. Convert it into bmp (you can use imagemagick or GIMP) and change DOS extension to ico.
Now, if the correct answer is, "the netbeans package as included in ascii is crap, don't use it, uninstall it and get the package from [wherever netbeans comes from] and install that", then i can do that. But if the answer SHOULD be "yeah somebody added a crap package, we'll fix that".
Netbeans package in Devuan is identical to the one from Debian. Devuan is Debian + no-systemd-dependencies overlay. So try to install NetBeanss from official site if you don't like package in repo.
ToxicExMachina wrote:Wayland is futureless non-working garbage made by incompetent wannabe-programmers.
You might want to read this blog post:
https://drewdevault.com/2019/02/10/Wayl … unked.html
Drew DeVault is the author of sway, I think he knows what he's talking about
No, he don't. Most of those "misconceptions" are fictional conclusions suitable for "debunking". I can tell a lot about wayland and X11. However, for this topic it's enoung to mention very demonstrative fact: 10 years of development without result. So no, it's wrong to remove a package because it doesn't work with wayland. According to that argument much more packages should be removed because even with XWayland not everything works properly.
ToxicExMachina wrote:Only idiot can remove working package in favor of wayland.
Well it certainly doesn't make much sense in Devuan, I think golinux is right and we'll see it back at some point.
Not that I would miss it...
I hope so.
The synaptic package was removed from the Debian buster repositories because it doesn't work under a Wayland session in GNOME:
Wayland is futureless non-working garbage made by incompetent wannabe-programmers. Only idiot can remove working package in favor of wayland.
ToxicExMachina wrote:Try to find "power on USB at startup" or "USB powersaving" option in CMOS setup or something like that.
I'm sorry there are no such options.
Can you boot different distro?
What's bullshit?
"Cracker" is used as a derogatory term for Caucasians, as my Wikipedia link shows and also as you yourself commented.
Wikipedia is bullshit.
https://tools.ietf.org/html/rfc1983
cracker
A cracker is an individual who attempts to access computer systems
without authorization. These individuals are often malicious, as
opposed to hackers, and have many means at their disposal for
breaking into a system. See also: hacker, Computer Emergency
Response Team, Trojan Horse, virus, worm.
ToxicExMachina wrote:It seems you don't know who genuine hackers are.
Panopticon wrote:and no a cracker is not that white skinned person in a black skinned neighborhood!
Yes, I'm aware that I used the terminology incorrectly but only because to me a "cracker" is exactly what Panopticon's quote describes so I just used the lazy, inaccurate term.
The fact: you said "genuine hackers" - not "hackers". Do you want to continue the nonsense you doing?
Ron wrote:Making your own website looked hacked, that's the real stupidity.
Why would genuine hackers change the home page if they wanted to plant malware? Think about it...
It seems you don't know who genuine hackers are.
I dont see the point in spotify
Me too.
Try to find "power on USB at startup" or "USB powersaving" option in CMOS setup or something like that.
The only way to install such software with any degree of safety is to create a chroot and install it there - but it's still not to be considered trustworthy. As I understand it, it's a binary distribution, so you're somewhat hamstrung, but without resorting to a chroot, you could also unpack the deb and manually install the components under /usr/local , create symbolic links, etc...
debootstrap + schroot + firejail = relatively secure way for third party repos.
1. Create separated root filesystem with debootstrap
2. Install packages into chroot environment
3. Run program via firejail and schroot
You can use any installer you want. 64-bit is better because recent versions of software are designed for it.
ToxicExMachina wrote:in system totally controlled by microsoft-friendly company (RedHat and Canonical are friends of microsoft) is not a good idea
Using Spotify is not a good idea but that's what the OP wants and IMO a sandboxed chroot is a better option than handing control of APT to the Spotify developers.
Yes. And he don't need another third party wannabe-"secure" package manager for that.
Oh, and RedHat, Cannonical and Microsoft are all contributors to the Linux kernel itself.
The subject is not kernel.
ToxicExMachina wrote:AppImage has FireJail sandbox support.
All programs have firejail "support", that's not an intrinsic feature of AppImages.
man firejail
ToxicExMachina wrote:According to official website Spotify doesn't provide official flatpak builds.
I didn't claim otherwise, my question was are there any Spotify AppImages available at all?
Maybe someone made a package. I don't know. However, there is no official flatpak package.
ToxicExMachina wrote:there is official deb repository.
Why do you think it is acceptable to hand the APT keys over to a proprietary company?
I don't think about that - user should decide the grade of acceptance.
As I mentioned earlier, flatpak can be run without root permissions, which seems significantly safer to me.
Flatpak is systemd way. It's also extremely insecure thing with fake sandboxing: https://flatkill.org/
ToxicExMachina wrote:Both flatpak and snap are EEE projects
And what has that to do with anything?
Additional package manager in system totally controlled by microsoft-friendly company (RedHat and Canonical are friends of microsoft) is not a good idea.
ToxicExMachina wrote:AppImage is better
Well if that was the case then your previous statement would be false because the alternatives would lack the middle E...
In the case of flatpak the advantage is the sandbox provided by bubblewrap, it's not great security but it's better than nothing (which is what AppImages provide).
AppImage has FireJail sandbox support. So it's definitely much and much more than nothing.
ToxicExMachina wrote:AppImage is better
Also, do Spotify even provide an AppImage?
According to official website Spotify doesn't provide official flatpak builds. Moreover: there is official deb repository.
Besides, flatpak and/or snap instead of AppImage is a trait of incompetent upstream maintainer.
I may also suggest a totally open source alternative to Spotify: https://github.com/nukeop/nuclear
It has AppImage builds
Maybe you haven't installed required packages.
Try amdgpu (not amdgpu-pro) driver. It seems your GPU is GCN 1.1.
hi there everybody, new here, seems to be the right place. humour is essential.
Greetings
Humor is essential but this time that was too much.
Anyone have any experience/pointers on how to switch from the integrated controller to the discrete one?
You can try DRI_PRIME from Mesa. It's the most proper way to use hybrid graphics.
It's not forum - it's main site of the project.
^ Well I couldn't find a snapd package in the Devuan repositories
But seriously, I don't think giving the Spotify developers the opportunity to mess up the dependency chain is a good idea.
flatpak may be a bloated pile of crap but at least it can be run without root privileges (with the --user flag) and it doesn't interfere with the package manager.
Both flatpak and snap are EEE projects. AppImage is better because it's tarball evolution.
It would be good if this were given as an option during install. Personally I would prefer to drop to console rather than use a greeter.
The option is already in installer: install minimal system. After that you can install X11 and WM or DE. If you would like to login into console i think you know how to configure what you really need.
i am planing to put it at github
Since github becomes anti-opensource hosting i would recommend to consider gitlab as possible solution.
it maybe a garbage, but it can be faster than systemd
Can your init addon brick random motherboard and execute random code from random user with root privileges remotely? No? Then it's still better than systemd.
Too many posts under my name at the top of the list.
As it appears that the original ASRock motherboard was at least partially at fault for why the Ryzen 1600 would not work, it seems possible that that CPU is not a dud.
Taichi series are the only good motherboards from asrock. Other ones from this vendor have tons of issues.
I picked up a A320 motherboard on sale. If this Ryzen 1600 works, that's wonderful. But I doubt the application requires a 12 core CPU.
Motherboard based on low-end chipset is grave mistake for powerful pre-hi-end CPU. You need at least B350 based motherboard for Ryzen 5 1600. A320 is an office-PC grade chipset designed for first generation Ryzen 3 CPUs exclusively. Usually such motherboards can't provide enough energy for powerful CPUs.
Some problems may also be caused by opcache. In firmware setup you should turn it off because in early revisions of first generation Ryzen CPUs there is a hardware bug in opcache.
amdgpu is the only module you need for graphics. If you want recent OpenCL implementation try ROCm from AMD: https://rocm.github.io/ROCmInstall.html
Devuan is using the same service management as pre-systemd Debian (see sysv-rc and "service" command). If you want a bare minimal setup out of box - netinstall is for you.