Re: Synchronet BBS
By: Capn Jax to All on Mon Jun 08 2020 07:52 am
I've got an old Toshiba Sattelite laptop using Vista. Can I set up a BB using it?
Yep. I have a Dell Inpiron E1505 laptop also with Vista which I'm using for mine. One of these days I'll upgrade to something newer, but for now this i working fine, and it's able to run all my 16-bit DOS doors.
I tried upgrading from Vista to Windows 10. I even got a tech from microsoft to guide me and found it impossible. I'll use the lapyop and see what I can setup.
On 10-09-20 13:56, Nightfox wrote to Capn Jax <=-
@VIA: VERT/DIGDIST
Re: BBS using Vista
By: Capn Jax to Codefenix on Fri Oct 09 2020 02:41 pm
I tried upgrading from Vista to Windows 10. I even got a tech from microsoft to guide me and found it impossible. I'll use the lapyop and see what I can setup.
I thought officially you could upgrade from Windows 7 to Windows 10,
but not from earlier versions of Windows. If you're using a version earlier than Windows 7, the best bet might be to re-install fresh.
Nightfox wrote to Capn Jax <=-
Re: BBS using Vista
By: Capn Jax to Codefenix on Fri Oct 09 2020 02:41 pm
I tried upgrading from Vista to Windows 10. I even got a tech from microsoft to guide me and found it impossible. I'll use the lapyop and see what I can setup.
I thought officially you could upgrade from Windows 7 to Windows 10,
but not from earlier versions of Windows. If you're using a version earlier than Windows 7, the best bet might be to re-install fresh.
Re: Synchronet BBS
By: Codefenix to Capn Jax on Tue Jun 09 2020 08:02:43
I tried upgrading from Vista to Windows 10. I even got a tech from microsoft to guide me and found it impossible. I'll use the lapyop and
see what I can setup.
... Capn Jax scribbled to Codefenix in the sand ...
Re: Synchronet BBS
By: Codefenix to Capn Jax on Tue Jun 09 2020 08:02:43
I tried upgrading from Vista to Windows 10. I even got a tech from
microsoft to guide me and found it impossible. I'll use the lapyop
and see what I can setup.
My guess would be to upgrade to Windows 7 first then upgrade to 10? Just a thought.
What all did Microsoft tell ya'?
Sincerely,
Jon Justvig
I was about to say the same thing, the upgrade supports only Win7 and later. I'd also recommend a fresh installation of Windows 10.
Re: Re: BBS using Vista
By: Jon Justvig to Capn Jax on Sat Oct 10 2020 08:55 am
I tried upgrading from Vista to Windows 10. I even got a tech from
microsoft to guide me and found it impossible. I'll use the lapyop
and see what I can setup.
My guess would be to upgrade to Windows 7 first then upgrade to 10? Just a thought.
i wouldn't even upgrade. i would just save my files and do a full win10 install. ---
A fresh install would be ideal with a system without a lot of stuff to transfer over. Nowdays, even a thumb drive has enough storage. It just depends on the person's preference. It's been too many years to count since I've touched Vista.
Re: Re: BBS using Vista
By: Jon Justvig to MRO on Sat Oct 10 2020 02:35 pm
A fresh install would be ideal with a system without a lot of stuff to transfer over. Nowdays, even a thumb drive has enough storage. It just depends on the person's preference. It's been too many years to count since I've touched Vista.
I usually like having a system with 2 separate drives. I keep things
like music, photos, etc. on the second drive (usually D) and Windows on
C, so if I have to re-install Windows, usually the only things I have
to transfer over are my user files & settings, and re-install the
software I use often.
Re: Re: BBS using Vista
By: Vk3jed to Nightfox on Sat Oct 10 2020 05:59 pm
I was about to say the same thing, the upgrade supports only Win7 and later. I'd also recommend a fresh installation of Windows 10.
I was using Windows 7 on my previous desktop PC. When Windows 10 came out, you could upgrade to Windows 10 for free for a limited time, and I took the Windows 10 upgrade. It upgraded via the internet and seemed
to go smoothly.
Many would agree that having 2 seperate drives, particularlly virtual machines are best they're on a a different drive. As you said, the first
I still much prefer Linux as it's free all the way around and doesn't seem to 'break' as easy as Windows does. I guess because it's not made out of glass? <lol>
A fresh install would be ideal with a system without a lot of stuff to transfer over. Nowdays, even a thumb drive has enough storage. It just depends on the person's preference. It's been too many years to count since I've touched Vista.
I've thought it would be funny to make my own OS, and instead of Windows, I'd call it Doors. Its slogan could be "Break On Through" (as in the Doors song).
Re: Re: BBS using Vista
By: Jon Justvig to Nightfox on Sat Oct 10 2020 06:01 pm
Many would agree that having 2 seperate drives, particularlly virtual machines are best they're on a a different drive. As you said, the first
Why a virtual machine? Do you mean having a different OS running in a
VM to store things on the 2nd drive?
Re: Re: BBS using Vista
By: Jon Justvig to Nightfox on Sat Oct 10 2020 06:04 pm
I still much prefer Linux as it's free all the way around and doesn't seem to 'break' as easy as Windows does. I guess because it's not made out of glass? <lol>
I've thought it would be funny to make my own OS, and instead of
Windows, I'd call it Doors. Its slogan could be "Break On Through" (as
in the Doors song).
Re: Re: BBS using Vista
By: Jon Justvig to MRO on Sat Oct 10 2020 02:35 pm
A fresh install would be ideal with a system without a lot of stuff to transfer over. Nowdays, even a thumb drive has enough storage. It just depends on the person's preference. It's been too many years to count since I've touched Vista.
i dont trust any upgrades. i would rather reinstall
On 10-10-20 11:17, Nightfox wrote to Vk3jed <=-
I was using Windows 7 on my previous desktop PC. When Windows 10 came out, you could upgrade to Windows 10 for free for a limited time, and I took the Windows 10 upgrade. It upgraded via the internet and seemed
to go smoothly.
i dont trust any upgrades. i would rather reinstall
Now under Linux is a different story. Especially Ubuntu, it has a great method of upgrading the OS while perserving what's already on there as far as personal stuff and even upgrading the current applications and tools already on the system.
As did my Win 10 upgrade, but the OP was running Vista. The upgrade is only for 7 and later. Oh, and AFAIK, you can still upgrade for free. I did it last year. Microsoft never got rid of the free upgrade. :)
i dont trust that shit either. i bet if i did an upgrade on my server it would fuck up big time.
I remember hearing that the free Windows 10 upgrade was only for a limited time. I remember hearing when the free upgrade period ended. Maybe they brought it back.
I remember hearing that the free Windows 10 upgrade was only for a limited time. I remember hearing when the free upgrade period ended. Maybe they brought it back.
Kurisu wrote to Nightfox <=-
I remember hearing that the free Windows 10 upgrade was only for a limited time. I remember hearing when the free upgrade period ended. Maybe they brought it back.
They never actually ended it - they just didn't annoucnce that it
didn't end. By using the windows 10 setup assitant on a windows 7
machine things will just upgrade, and use the old license key.
Re: Re: BBS using Vista
By: Jon Justvig to MRO on Sun Oct 11 2020 01:35 am
i dont trust any upgrades. i would rather reinstall
Now under Linux is a different story. Especially Ubuntu, it has a great method of upgrading the OS while perserving what's already on there as far as personal stuff and even upgrading the current applications and tools already on the system.
i dont trust that shit either. i bet if i did an upgrade on my server
it would fuck up big time. ---
I remember hearing that the free Windows 10 upgrade was only for a
limited time. I remember hearing when the free upgrade period ended.
Maybe they brought it back.
They never actually ended it - they just didn't annoucnce that it didn't end. By using the windows 10 setup assitant on a windows 7 machine things will just upgrade, and use the old license key.
Can you explain that in a little more detail? How does one run
the "windows 10 setup assistant" on a windows 7 machine?
I'm asking because I'd like to try it.
I thought I specifically saw an announcement that the free upgrade period had ended and users would have to pay for an upgrade to Windows 10.
The tech finally told me that toshiba laptop I had usinf Vista could not be changed to anything else. The laptop I'm using now was upgraded from 7 to 10 and runs fine.
On 10-11-20 10:04, Nightfox wrote to Vk3jed <=-
I remember hearing that the free Windows 10 upgrade was only for a
limited time. I remember hearing when the free upgrade period ended. Maybe they brought it back.
I thought I specifically saw an announcement that the free upgrade period had ended and users would have to pay for an upgrade to Windows 10.
Nightfox wrote to Vk3jed <=-
I was using Windows 7 on my previous desktop PC. When Windows 10 came out, you could upgrade to Windows 10 for free for a limited time, and I took the Windows 10 upgrade. It upgraded via the internet and seemed
to go smoothly.
Kurisu wrote to Gamgee <=-
Can you explain that in a little more detail? How does one run
the "windows 10 setup assistant" on a windows 7 machine?
I'm asking because I'd like to try it.
I phrased it wrong because of course I would - https://www.microsoft.com/en-us/software-download/windows10
you want to download the media creation tool, and simply upgrade
your system. It's really kind of amazing how generally
straightforward it is.
I thought I specifically saw an announcement that the free upgrade period had ended and users would have to pay for an upgrade to Windows 10.
Nightfox
Kurisu wrote to Nightfox <=-
Best most discussion points at is that MS would rather have systems upgraded, even at a loss. People and, more importantly, business, will
buy new machines down the line anyway, and thus licenses will be sold
with them, and big business will most likely buy licenses anyway so....
--- MRO wrote --
By: Nightfox to Jon Justvig on Sat Oct 10 2020 06:12 p
I've thought it would be funny to make my own OS, and instead of Wind I'd call it Doors. Its slogan could be "Break On Through" (as in the song).
this reads like a jack handy quot
I got an old machine with a Win7 COA that I need to install and upgrade to 10. We did a ton of these at work recently and all have gone fine, so... yeah, free upgrades abound.
FYI, if you're doing a clean install, you can install win10 directly and
use the win7/8 key.
mark firestone wrote to MRO <=-
--- MRO wrote --
By: Nightfox to Jon Justvig on Sat Oct 10 2020 06:12 p
I've thought it would be funny to make my own OS, and instead of Wind I'd call it Doors. Its slogan could be "Break On Through" (as in the song).
this reads like a jack handy quot
Remember when Windows 95 came out, they used "Start Me Up" by The
Rolling Stones?
They had to remove the line, "You make a grown man cry..."
--- DENNISK wrote --
Have you heard the party version of the song, Windows 95
http://youtube.com/watch?v=4sH6lopuzd
FYI, if you're doing a clean install, you can install win10 directly and
use the win7/8 key.
I've heard with Win10 you can just not put in a key or register and the OS will
run with only a minimal restriction. Linus Media Group always talks about it because their test videos usually have unregistered copies of Win10 running. Basically they just said, the OS performs normally even if not registered, so why bother?
I may be wrong though.
I've heard with Win10 you can just not put in a key or register and the OS will run with only a minimal restriction. Linus Media Group always talks about it because their test videos usually have unregistered copies of Win10 running. Basically they just said, the OS performs normally even if not registered, so why bother?
I've heard with Win10 you can just not put in a key or register and
the OS will run with only a minimal restriction. Linus Media Group
I think the main limitation is not being able to change the wallpaper, and the unregistered nag in the bottom right corner, though I often get this running insiders builds anyway, so less concerned about it.
mark firestone wrote to DENNISK <=-
--- DENNISK wrote --
Have you heard the party version of the song, Windows 95
http://youtube.com/watch?v=4sH6lopuzd
Heh. That was pretty good!
Android8675 wrote to Tracker1 <=-
FYI, if you're doing a clean install, you can install win10 directly and
use the win7/8 key.
I've heard with Win10 you can just not put in a key or register
and the OS will run with only a minimal restriction. Linus Media
Group always talks about it because their test videos usually
have unregistered copies of Win10 running. Basically they just
said, the OS performs normally even if not registered, so why
bother?
I may be wrong though.
Re: Re: BBS using Vista
By: Tracker1 to Android8675 on Wed Oct 14 2020 09:46 am
I've heard with Win10 you can just not put in a key or register and
the OS will run with only a minimal restriction. Linus Media Group
I think the main limitation is not being able to change the wallpaper, and the unregistered nag in the bottom right corner, though I often get this running insiders builds anyway, so less concerned about it.
Another limitation is that you can't enable desktop icons such as the 'Compu
One trick I've found, though, is that if you install Win10 without being con Then after you change some settings, you can go ahead and connect it to the
Nightfox
One trick I've found, though, is that if you install Win10 without
being con Then after you change some settings, you can go ahead and
connect it to the
My understanding is the timer goes off after a month, then the watermark appears that sya to activate Windows. Anything connected to personalization is deactivated.
Well, one reason to bother is that you're breaking the law
My experience is that if you have Win10 connected to the internet, then you immediately can't personalize it without activating it with a valid key.
My experience is that if you have Win10 connected to the internet,
then you immediately can't personalize it without activating it with a
valid key.
Interesting. I guess mine have always been activated automatically with the UEFI keys. I don't think I've ever had to actually type an activation code for Windows 10.
Android8675 wrote to Gamgee <=-
Well, one reason to bother is that you're breaking the law
https://youtu.be/BXtPycm5dGc?t=35
--- NIGHTFOX wrote ---
What is a UEFI key? I'm not familiar with that. Typically I build my own desktop PC and buy an OEM copy of Windows, where I have to enter a license key, or I might buy a laptop which already has Windows installed on it.
What is a UEFI key? I'm not familiar with that. Typically I build my
own desktop PC and buy an OEM copy of Windows, where I have to enter a
license key, or I might buy a laptop which already has Windows
installed on it.
Keys built into the BIOS. That's why, at work, I can rebuild a Dell laptop and just install Windows on it, without entering any keys...
OS keys built into the BIOS? Interesting..
Re: Re: BBS using Vista
By: Nightfox to Moondog on Thu Oct 15 2020 08:06 am
My experience is that if you have Win10 connected to the internet, then you immediately can't personalize it without activating it with a valid key.
Interesting. I guess mine have always been activated automatically
with the UEFI keys. I don't think I've ever had to actually type an activation code for Windows 10.
--- NIGHTFOX wrote ---
What is a UEFI key? I'm not familiar with that. Typically I build my own desktop PC and buy an OEM copy of Windows, where I have to enter a license key, or I might buy a laptop which already has Windows installed on it.
Keys built into the BIOS. That's why, at work, I can rebuild a Dell laptop and just install Windows on it, without entering any keys...
Re: Re: BBS using Vista
By: Nightfox to the doctor on Fri Oct 16 2020 08:06 am
OS keys built into the BIOS? Interesting..
That's not quite what's going on.
To phrase it simply, Microsoft associates a given key with identifiers
of a system, such as a board serial number, particular UEFI ID's and
the like - whatever "works" to identify a system uniquely.
It pairs the regestration of the Windows product key to that unique hardware, and thus when it sees an activation request from that
machine, it knows "oh, this is paired to this license key, it's valid, activate it" making re-installs trivial.
It's a pretty nice system, presuming of course MS's systems are working properly. _____
laptop and just install Windows on it, without entering any keys...
OS keys built into the BIOS? Interesting..
It's a pretty nice system, presuming of course MS's systems are working properly.
_____
Kurisu wrote to Nightfox <=-
Re: Re: BBS using Vista
By: Nightfox to the doctor on Fri Oct 16 2020 08:06 am
OS keys built into the BIOS? Interesting..
That's not quite what's going on.
To phrase it simply, Microsoft associates a given key with identifiers
of a system, such as a board serial number, particular UEFI ID's and
the like - whatever "works" to identify a system uniquely.
It pairs the regestration of the Windows product key to that unique hardware, and thus when it sees an activation request from that
machine, it knows "oh, this is paired to this license key, it's valid, activate it" making re-installs trivial.
It's a pretty nice system, presuming of course MS's systems are working properly. _____
So its a feature which places artificial limitations on hardware, in
order to support limitations on software?
a while back i was getting points for amazon cards with my bing searches.
i wasnt even using bing that much even though it's pretty much better than google search sometimes. i wonder if they still do that.
Re: Re: BBS using Vista
By: Dennisk to Kurisu on Mon Oct 05 2020 05:39 am
So its a feature which places artificial limitations on hardware, in order to support limitations on software?
And this is progress?
Windows needs to die a fiery death. Stallman was right about proprietary software.
it aint hurting anybody.
Re: Re: BBS using Vista
By: Dennisk to Kurisu on Mon Oct 05 2020 05:39 am
So its a feature which places artificial limitations on hardware, in order to support limitations on software?
....no? It's a system to make reinstalls easy and that's about it? Windows h been tying license keys to hardware configs in some way for damn near 20 yea since XP and activation. Licenses keys CAN be migrated between systems if on needs to - the obvious requirement being that copy of Windows on that old hardware is no longer used.
I can't even begin to see what you mean about "artificial limitations on hardware" and barely find the software "limited" beyond the above which is purely enforcement of already existing licensing.
You may hate MS and Windows and that's fine - prefer what you wish - but don completely distort what something is to fit a personal agenda against something, especially when in practice the aspect you're trying to make a bi deal out of isn't anything new for the OS in question.
_____
Kurisu Yamato
www.xadara.com
--- MRO wrote ---
Windows needs to die a fiery death. Stallman was right about
proprietary software.
it aint hurting anybody.
fact. They've put the service into Xbox as well, so I even get points for gaming when I do.. you know, once a month now or so. >_>
Used to get free years of Xbox live with it. Now I get GamePass Ultimate. My friend still does the Amazon cards constantly. He always buys little crap with what he gets from them, so it's a win-win on his end, saving money where he can. :D
Windows needs to die a fiery death. Stallman was right about
proprietary software.
it aint hurting anybody.
Well, it hurts ME when it degrades due top regular operating system operation and I get relatives chasing me asking to fix it.
A lot like smartphones, actually.
I think his issue is that you have to perform operating system activation at all, automated or not.
i can tell that google search is going overboard with messing with people's search results so i may go back to bing or try to find something different.
i can tell that google search is going overboard with messing with people's search results so i may go back to bing or try to find something different.
Arelor wrote to Kurisu <=-
Re: Re: BBS using Vista
By: Kurisu to Dennisk on Fri Oct 16 2020 08:56 pm
Re: Re: BBS using Vista
By: Dennisk to Kurisu on Mon Oct 05 2020 05:39 am
So its a feature which places artificial limitations on hardware, in order to support limitations on software?
....no? It's a system to make reinstalls easy and that's about it? Windows h been tying license keys to hardware configs in some way for damn near 20 yea since XP and activation. Licenses keys CAN be migrated between systems if on needs to - the obvious requirement being that copy of Windows on that old hardware is no longer used.
I can't even begin to see what you mean about "artificial limitations on hardware" and barely find the software "limited" beyond the above which is purely enforcement of already existing licensing.
You may hate MS and Windows and that's fine - prefer what you wish - but don completely distort what something is to fit a personal agenda against something, especially when in practice the aspect you're trying to make a bi deal out of isn't anything new for the OS in question.
_____
Kurisu Yamato
www.xadara.com
I think his issue is that you have to perform operating system
activation at all, automated or not.
Specially because when you come from the Linux or BSD world, these
things feel very alien and intrusive. I mean, I have comercial software running on Linux and BSD servers but I never had to activate it with
codes or anything.
Then you have things like Autodesk. When I was at college they gave you
a free student license for engineering CAD software, but the activation process sucked so much that you ended up cracking the product instead.
So, well, activation procedures are a limit set on purpose by the manufacturer so he can make bucks more easily. So Dennisk has a point there. I don't have an _ethical_ problem with activation procedures,
but sometimes they suck so much they deserve to die by fire.
--
gopher://gopher.operationalsecurity.es
Re: Re: BBS using Vista
By: MRO to Kurisu on Sat Oct 17 2020 10:52 am
i can tell that google search is going overboard with messing with
people's search results so i may go back to bing or try to find
something different.
How about DuckDuckGo? DuckDuckGo says they value your privacy (if you believe them(.
i can tell that google search is going overboard with messing with people's search results so i may go back to bing or try to find somet different.
How about DuckDuckGo? DuckDuckGo says they value your privacy (if you believe t hem(.
the doctor wrote to NIGHTFOX <=-
Keys built into the BIOS. That's why, at work, I can rebuild a Dell laptop and just install Windows on it, without entering any keys...
Interesting. I guess mine have always been activated automatically with
the UEFI keys. I don't think I've ever had to actually type an activation
code for Windows 10.
What is a UEFI key? I'm not familiar with that. Typically I build my own desktop PC and buy an OEM copy of Windows, where I have to enter a license key, or I might buy a laptop which already has Windows installed on it.
So its a feature which places artificial limitations on hardware, in
order to support limitations on software?
And this is progress?
Windows needs to die a fiery death. Stallman was right about
proprietary software.
Yeah, the fact it also links to the MS account is just awesome! Forgot to mention that in my post, but yeah. MS accounts are so bloody useful... about like an Apple account but, you know, for Microsoft stuff! haha...
Hey it ties in with my Xbox and that's all that matters. :P
a while back i was getting points for amazon cards with my bing searches.
i wasnt even using bing that much even though it's pretty much better than google search sometimes. i wonder if they still do that.
Well, it hurts ME when it degrades due top regular operating system operation and I get relatives chasing me asking to fix it.
A lot like smartphones, actually.
Yes, kind of. The problem isn't specifically UEFI, it is Secure Boot
which can place an impediment on people. Granted in the majority of
cases, the user has control, and I do admit it can also be advantageous, although personally I don't think so.
Except when you have a personal, and office account and need to access
your office account's MS Office software on your machine setup with your personal account, and the Office registration/activation goes a little wonky...
Tracker1 wrote to Dennisk <=-
On 10/5/2020 3:39 AM, Dennisk wrote:
So its a feature which places artificial limitations on hardware, in
order to support limitations on software?
No... there are no artificial limitations on hardware, it's just a key
in the bios that stores the registration key for windows on that
device, you can always use a different key at install or change it for
a different windows version.
And this is progress?
In terms of user convenience, absolutely... it allows a fast path to a clean windows install over trying to clear out bloatware after the
fact.
Windows needs to die a fiery death. Stallman was right about
proprietary software.
While I mostly agree, Windows really doesn't bother me *that* much
these days... I find the forced update/restart somewhat annoying, but
on the flip side of having had to support some friends and family, I'd rather they were always updated/current on their software in general.
It's not like the average computer user could handle even a major dist upgrade when errors do happen, even if they stuck to LTS releases. Of course appImage/flatpak/snap can help with that, but I'm guessing
you're also opposed to those as well.
Tracker1 wrote to Dennisk <=-
On 10/5/2020 8:43 AM, Dennisk wrote:
Yes, kind of. The problem isn't specifically UEFI, it is Secure Boot
which can place an impediment on people. Granted in the majority of
cases, the user has control, and I do admit it can also be advantageous, although personally I don't think so.
My only real issue with Secure Boot, is when you can't disable it as
has happened with some MS (and Intel) hardware specifically.
On 10/17/2020 3:06 AM, Arelor wrote:
Well, it hurts ME when it degrades due top regular operating system operat and I get relatives chasing me asking to fix it.
A lot like smartphones, actually.
So you've *NEVER* had dist upgrade fail on you, or create error
conditions in software you use? Or had hardware regressions, or other
odd behaviors... Or had to switch to a beta/dev kernel to support
hardware to work around previously mentioned issues and then had other things break as a result?
No imagine trying to troubleshoot/fix *THAT* over the phone.
--
Michael J. Ryan
tracker1 +o Roughneck BBS
Well, one reason to bother is that you're breaking the law
How....... juvenile.
Tracker1 wrote to Kurisu <=-
Except when you have a personal, and office account and need to access your office account's MS Office software on your machine setup with
your personal account, and the Office registration/activation goes a little wonky...
Tracker1 wrote to Arelor <=-
So you've *NEVER* had dist upgrade fail on you, or create error
conditions in software you use? Or had hardware regressions, or other
odd behaviors... Or had to switch to a beta/dev kernel to support
hardware to work around previously mentioned issues and then had other things break as a result?
No imagine trying to troubleshoot/fix *THAT* over the phone.
On 10/16/2020 7:19 PM, MRO wrote:
a while back i was getting points for amazon cards with my bing
searches. i wasnt even using bing that much even though it's pretty
much better than google search sometimes. i wonder if they still do
that.
Which is funny, considering Bing used Google search to train it's systems.
I'm all for a good package management system. I just don't think the options you cited are good systems. They solve the wrong problem.
Are you able to generate your own BIOS key?
My only real issue with Secure Boot, is when you can't disable it as
has happened with some MS (and Intel) hardware specifically.
That is the big concern I have. It's one step from it being an option to disable, to it not being available. And there are many arguments that companies can make to disable it, or at least make their OS refuse to boot if it is disabled.
So you've *NEVER* had dist upgrade fail on you, or create error
conditions in software you use? Or had hardware regressions, or other
odd behaviors... Or had to switch to a beta/dev kernel to support
hardware to work around previously mentioned issues and then had other
things break as a result?
Now imagine trying to troubleshoot/fix *THAT* over the phone.
Honestly I don't get the fear of distro upgrades in small systems.
I have never had a dist upgrade fail on a consumer system.
I had one hardware regression - propietary kernel module which had to be replaced because the manufacturer stopped supporting new kernels - in a consumer system.
I have faced some breakage on non-consumer systems with database migrations and
such, but then 1) this does not apply to consumers and 2) that is why production systems have failovers and switchovers and testing environments.
Main office in the clinic is running Linux workstations only. I currentl¤y support ONE Windows install, which is my mother's. About 70% or the support phone calls I get are for Window's problems.
So, hmm, you are not exactly scaring me a lot with Linux dist upgrade failures.
Heck, I don't remember an OpenBSD os upgrade failure either, and those used to
involve a lot of manual work.
Had the issue a few days ago... on a loaner/temp laptop for work, andExcept when you have a personal, and office account and need to access
your office account's MS Office software on your machine setup with
your personal account, and the Office registration/activation goes a
little wonky...
I haven't run into that, and I have both a work and personal account
loaded up; I need to in order to load a personal OneNote notebook with
tech notes in it along with my work notebook with meeting notes.
Tracker1 wrote to Dennisk <=-options
On 10/19/2020 7:33 PM, Dennisk wrote:
I'm all for a good package management system. I just don't think the
you cited are good systems. They solve the wrong problem.
While I understand, that said the full package systems like flatpak
allow for dependencies to not be an issue and for complex application sthat can be a big problem, especially with a distro upgrade, which
always blows up something in my experience.
Are you able to generate your own BIOS key?
I'm not sure tbh, I'm not really familiar with how the backend for it works, or if it's a general (U)EFI firmware feature.
While I understand, that said the full package systems like flatpak
allow for dependencies to not be an issue and for complex application
sthat can be a big problem, especially with a distro upgrade, which
always blows up something in my experience.
These can be solved with better discipline and standards though. As much as I
like Linux, Windows has an advantage here. Having that central control means that there is a better chance that you develop for one specific platform and have it work.
Flatpak means that Linux has failed as a platform. If you can't develop a program for that platform, without having to include a significant copy of that
platform because that platform will break your program, there is a serious deficiency somewhere.
I get what its trying to solve, but its like someone using their forehead to bang nails into wood, and then "solves" the problem of a sore head by screwing
a metal plate to their forehead.
Tracker1 wrote to Dennisk <=-I
On 10/20/2020 6:13 PM, Dennisk wrote:
While I understand, that said the full package systems like flatpak
allow for dependencies to not be an issue and for complex application
sthat can be a big problem, especially with a distro upgrade, which
always blows up something in my experience.
These can be solved with better discipline and standards though. As much as
like Linux, Windows has an advantage here. Having that central controlmeans
that there is a better chance that you develop for one specific platform and have it work.
Okay, so you don't use the centrally managed/controlled package manager for your distro? And how does that jive with your specific platform
and have it work? Also, it means you're less likely to get
applications support on less popular distros.
I mean, if you don't care if actual people can get the applications
they actually need, that's fine, but it's not going to work for most people.
Flatpak means that Linux has failed as a platform. If you can't develop a program for that platform, without having to include a significant copy oftha
tscrewing
platform because that platform will break your program, there is a serious deficiency somewhere.
You act like Linux is a single platform... there are variances between versions and distros that cause and bring a *LOT* of variance. Have
you ever had to support Linux for software before? Did you limit
yourself to the main two distros only?
I get what its trying to solve, but its like someone using their forehead to bang nails into wood, and then "solves" the problem of a sore head by
a metal plate to their forehead.
Then create a better solution that works across differing linux distros
in a common way... Until then, it works well.
Okay, so you don't use the centrally managed/controlled package manager
for your distro? And how does that jive with your specific platform
and have it work? Also, it means you're less likely to get
applications support on less popular distros.
I mean, if you don't care if actual people can get the applications
they actually need, that's fine, but it's not going to work for most
people.
Yes, I use Yum and RPM. What is your point? They are vastly different Flatpak.
And it does work.
Then create a better solution that works across differing linux distros
in a common way... Until then, it works well.
There are already solutions. The problem is people cannot make them
work. There is utterly no point creating Yet Another Great Packaging
System when there isn't the discipline to make the existing ones work.
The whole philosophy of "lets create a solution, get coding" is
wrongheaded. The problem isn't that someone hasn't written the right
code, the problem is one of organisation and standards.
Windows has the advantage here because there is one canonical Windows, whereas anyone can make their own "Linux" which may or may not behave
with existing work.
If you are a developer, you have to figure out how to package it, and
take into account the different nuances between distros. For a platform which only has a few percent desktop market share, it seems a cruel joke
to have to go through this.
Again, Flatpak is not RPM or DEB. It is a parallel installation,
installing dependencies in addition to your system, which leads to
bloat. Snap was convoluted. AppImage seemed OK though.
Tracker1 wrote to Dennisk <=-
There are already solutions. The problem is people cannot make them
work. There is utterly no point creating Yet Another Great Packaging
System when there isn't the discipline to make the existing ones work.
The whole philosophy of "lets create a solution, get coding" is
wrongheaded. The problem isn't that someone hasn't written the right
code, the problem is one of organisation and standards.
appImage, flatpak and snaps work on every distro, yum doesn't.
If you are a developer, you have to figure out how to package it, and
take into account the different nuances between distros. For a platform which only has a few percent desktop market share, it seems a cruel joke
to have to go through this.
Yeah, I'll make appImage and flatpak available... fuck
distro-specific packaging.
Again, Flatpak is not RPM or DEB. It is a parallel installation,
installing dependencies in addition to your system, which leads to
bloat. Snap was convoluted. AppImage seemed OK though.
The app has all the dependencies included yes, that said, modern
hard drives are *MASSIVE* and it's better than dealing with the
linux version of DLL Hell.
Tracker1 wrote to Dennisk <=-
On 10/18/2020 6:57 PM, Dennisk wrote:
Okay, so you don't use the centrally managed/controlled package manager
for your distro? And how does that jive with your specific platform
and have it work? Also, it means you're less likely to get
applications support on less popular distros.
I mean, if you don't care if actual people can get the applications
they actually need, that's fine, but it's not going to work for most
people.
Yes, I use Yum and RPM. What is your point? They are vastly different Flatpak.
And it does work.
And if the developer behind an app you want uses Debian? Opps, sorry,
no app for you.
Then create a better solution that works across differing linux distros
in a common way... Until then, it works well.
There are already solutions. The problem is people cannot make them
work. There is utterly no point creating Yet Another Great Packaging
System when there isn't the discipline to make the existing ones work.
The whole philosophy of "lets create a solution, get coding" is
wrongheaded. The problem isn't that someone hasn't written the right
code, the problem is one of organisation and standards.
appImage, flatpak and snaps work on every distro, yum doesn't.
Windows has the advantage here because there is one canonical Windows,
whereas anyone can make their own "Linux" which may or may not behave
with existing work.
That's my point...
If you are a developer, you have to figure out how to package it, and
take into account the different nuances between distros. For a platform which only has a few percent desktop market share, it seems a cruel joke
to have to go through this.
Yeah, I'll make appImage and flatpak available... fuck distro-specific packaging.
Again, Flatpak is not RPM or DEB. It is a parallel installation,
installing dependencies in addition to your system, which leads to
bloat. Snap was convoluted. AppImage seemed OK though.
The app has all the dependencies included yes, that said, modern hard drives are *MASSIVE* and it's better than dealing with the linux
version of DLL Hell.
Gamgee wrote to Tracker1 <=-
Tracker1 wrote to Dennisk <=-
There are already solutions. The problem is people cannot make them
work. There is utterly no point creating Yet Another Great Packaging
System when there isn't the discipline to make the existing ones work.
The whole philosophy of "lets create a solution, get coding" is
wrongheaded. The problem isn't that someone hasn't written the right
code, the problem is one of organisation and standards.
appImage, flatpak and snaps work on every distro, yum doesn't.
Well, perhaps "many" distros, but not "every" distro.
I don't use any of the above, but a quick check on Flatpak said
that it works on 28 distros (listed), but my distro of choice
(Slackware) wasn't on the list.
If you are a developer, you have to figure out how to package it, and
take into account the different nuances between distros. For a platform which only has a few percent desktop market share, it seems a cruel joke
to have to go through this.
Yeah, I'll make appImage and flatpak available... fuck
distro-specific packaging.
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
Again, Flatpak is not RPM or DEB. It is a parallel installation,
installing dependencies in addition to your system, which leads to
bloat. Snap was convoluted. AppImage seemed OK though.
The app has all the dependencies included yes, that said, modern
hard drives are *MASSIVE* and it's better than dealing with the
linux version of DLL Hell.
I've not (ever) had that problem, and have been using Slackware
for roughly 20 years. <SHRUG>
Dennisk wrote to Gamgee <=-
I've tried FlatPak apps (because of having no alternative), and
it was not a better user experience. No ability to install via
the GUI, no integration with DNF Dragora, have to learn a
parallel package system, convoluted program starting process.
I installed signal by means of Flatpak, and you don't get a menu
item, or even a binary in /usr/bin/ where I can just type
'signal'. I have to do 'flatpak run org.signal.Signal'.
appImage, flatpak and snaps work on every distro, yum doesn't.
Well, perhaps "many" distros, but not "every" distro.
I don't use any of the above, but a quick check on Flatpak said
that it works on 28 distros (listed), but my distro of choice
(Slackware) wasn't on the list.
If you are a developer, you have to figure out how to package it, and
take into account the different nuances between distros. For a platform >>> which only has a few percent desktop market share, it seems a cruel joke >>> to have to go through this.
Yeah, I'll make appImage and flatpak available... fuck
distro-specific packaging.
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
Again, Flatpak is not RPM or DEB. It is a parallel installation,
installing dependencies in addition to your system, which leads to
bloat. Snap was convoluted. AppImage seemed OK though.
The app has all the dependencies included yes, that said, modern
hard drives are *MASSIVE* and it's better than dealing with the
linux version of DLL Hell.
I've not (ever) had that problem, and have been using Slackware
for roughly 20 years. <SHRUG>
And if the developer behind an app you want uses Debian? Opps, sorry,
no app for you.
Ok, so if I'm a flatpak user and they only put out a snap? Or vice versa?
Replacing two standards with three (actually, ADDING three standards) doesn't make the situation better, does it?
Now I have to not only worry about whether I can use an RPM or DEB, but also AppImage, Snap or Flatpak. Three more systems to learn, to manage, which are opaque to my distros standard tools.
How that is BETTER is beyond me.
If I'm a packager, I now have MORE packages I have to put out?
How is that better?
appImage, flatpak and snaps work on every distro, yum doesn't.
Which is the standard? You mean to tell me I have to have three different concurrent package management systems, each with their own dependencies and copies of dependencies?
Now I have AppImage, Flatpak, Snap, DEB and RPM.
I struggle to see the improvement. Which package system do I use if I want to
distribute software?
Now lets say it means at MOST three packages, instead of a Ubuntu DEB, Fedora RPM, Centos RPM, ArchLinux package, we now have shifted fragmentation to the user. We sure we want to do that?
At the moment, if I want to download Zoom its simple, I select the Fedora RPM.
From MY POV, its a standard system.
Yeah, I'll make appImage and flatpak available... fuck distro-specific
packaging.
Now its either AppImage of Flatpak specific. Are you going to support my choice of package?
Or are we back where we started, where you use the solution you think is best,
which may or may not be the one I use.
That sounds great. More complexity. More moving parts. Now I have multiple copies of libgtk-3 to manage and sandboxed(?) parallel installations.
Sounds braindead if you ask me.
The app has all the dependencies included yes, that said, modern hard
drives are *MASSIVE* and it's better than dealing with the linux
version of DLL Hell.
So we now have multiple copies of the OS basically, and this is sold as an improvement?
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
That's fine, if you don't want broad linux usage and want it to be a
niche OS... the fact is, it isn't... there's ever increasing usage of
Linux, and your apparent desire to stop it from happening won't.
Or are we back where we started, where you use the solution you think is best,
which may or may not be the one I use.
That's still no different from you choosing RPM, and a developer may
only be using Debian (apt). Your platform may be stuck on a 3-4yo
version of the software with bugs, because your distro has no maintainer
for a given package.
Tracker1 wrote to Gamgee <=-
appImage, flatpak and snaps work on every distro, yum doesn't.
Well, perhaps "many" distros, but not "every" distro.
I don't use any of the above, but a quick check on Flatpak said
that it works on 28 distros (listed), but my distro of choice
(Slackware) wasn't on the list.
And if it's in debian's apt, it's still not on your distro, is
it?
They work across distros *FAR* more than anything else on
deck.
Yeah, I'll make appImage and flatpak available... fuck
distro-specific packaging.
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
That's fine, if you don't want broad linux usage and want it to
be a niche OS... the fact is, it isn't... there's ever increasing
usage of Linux, and your apparent desire to stop it from
happening won't.
And why isn't it fine if a developer creates an appImage or puts
it on flathub exactly?
The app has all the dependencies included yes, that said, modern
hard drives are *MASSIVE* and it's better than dealing with the
linux version of DLL Hell.
I've not (ever) had that problem, and have been using Slackware
for roughly 20 years. <SHRUG>
I'm so happy for you that you've never upgraded your distro, in
particular applications side-loaded outside a repo, and had any application break at all... good for you, that does fuck all for
everyone that does.
Arelor wrote to Gamgee <=-
Am I missing something here? Full disclosure - I'm not a
developer. But isn't it fine if a developer creates some
application, and provides the source code to whomever wants it?
Then the end user (for example, me) can either compile it that
way, or make a suitable package for installation. Or, have the
distro's "community" package it up. Works for Slackware.
The issue there is that most distributions are not Slackware,
Gentoo or OpenBSD.
I think you are a bit harsh there.
Gamgee is not trying to make Linux a niche OS. And Linux has become an industrial power on its own right without a standard packaging format, which suggests to me it is actualy not such a bad big deal.
Seriously, for the industrial areas where Linux totaly crushes opposition, i is all Red Hat. Red Hat everywhere. And some Red Hat disguised as Centos. So seriously, if you are trying to deploy a closed source database system and sell it, you make a package that works for Red Hat. Not a big deal, hahahaha
Then again, what devops are doing nowadays is put stuff in containers or jai or virtual machines so whether there are packages or not does not make a difference. Linux is crushing in HPC and datacenters, and the pinguin didn't need AppImage to get there.
Gamgee wrote to Dennisk <=-
Dennisk wrote to Gamgee <=-
I've tried FlatPak apps (because of having no alternative), and
it was not a better user experience. No ability to install via
the GUI, no integration with DNF Dragora, have to learn a
parallel package system, convoluted program starting process.
I installed signal by means of Flatpak, and you don't get a menu
item, or even a binary in /usr/bin/ where I can just type
'signal'. I have to do 'flatpak run org.signal.Signal'.
Yeah, screw that. Don't see any need whatsoever for stuff like
this, at least for my needs. Not sure why anyone would want it,
to be honest.
Tracker1 wrote to Dennisk <=-doesn't
On 10/28/2020 8:06 PM, Dennisk wrote:
And if the developer behind an app you want uses Debian? Opps, sorry,
no app for you.
Ok, so if I'm a flatpak user and they only put out a snap? Or vice versa?
A few softwares have made that choice... it's no different than a developer that only works with Debian, sorry Redhat users.
Replacing two standards with three (actually, ADDING three standards)
make the situation better, does it?
flathub works across a *massive* number of distributions... as does appImage. And the problem it solves is distribution upgrades breaking applications.
Now I have to not only worry about whether I can use an RPM or DEB, but also AppImage, Snap or Flatpak. Three more systems to learn, to manage, whichare
opaque to my distros standard tools.
How that is BETTER is beyond me.
Do you write software for cross-platform distribution?
If I'm a packager, I now have MORE packages I have to put out?
How is that better?
No, instead of potentially something for debian, redhat, ... etc. You
can publish to an appImage, or flathub. Flatpak/flathub are available across *MANY* distributions, not just the one or two a developer may
have experience with. All dependencies are generally self contained.
appImage, flatpak and snaps work on every distro, yum doesn't.
Which is the standard? You mean to tell me I have to have three different concurrent package management systems, each with their own dependencies and copies of dependencies?
And apt and rpm aren't anything more *standard* are they? And as to
the dependencies, most of the dependencies are the same, and built in
with the kernel at this point.
Now I have AppImage, Flatpak, Snap, DEB and RPM.to
I struggle to see the improvement. Which package system do I use if I want
distribute software?
In terms of build, I would target appimage and flatpak, with
distribution on flathub, or on the source repository's distribution for appimage builds. I, frankly wouldn't worry about snap, but that would
be me, snap is mostly only on Ubuntu and isn't seeing broad support compared to flatpack/flathub.
If it's headless software, then I might be inclined to package toBut others may think Snap is where it is at, and put out Snap packages, not FlatPak (I have seen this). So users then have to contend with multiple systems.
Docker as well.
Now lets say it means at MOST three packages, instead of a Ubuntu DEB,Fedora
RPM, Centos RPM, ArchLinux package, we now have shifted fragmentation to the user. We sure we want to do that?
For the most part, flathub has the most broad support for centralized distribution (or Docker for headless server softwate), and is likely
the only thing that should be considered for most moving forward.
Snap doesn't have quite the broad support across distros and will
likely eventually go away and Ubuntu will shift to include
flatpak/flathub in the box. (speculation).
From a developer/publisher standpoint, this means at most supporting 3 systems, not 20+.
At the moment, if I want to download Zoom its simple, I select the FedoraRPM.
From MY POV, its a standard system.best,
And if the application isn't in RPM, you can download an appimage, or
load flathub... likely it's available on your distro, many are
including support for both out of the box even. On my linux desktop,
the results are even co-mingled with my application search/install UI.
Yeah, I'll make appImage and flatpak available... fuck distro-specific
packaging.
Now its either AppImage of Flatpak specific. Are you going to support my choice of package?
No, I will publish to appimage and on flathub... every major
distribution supports both of those two options.
Or are we back where we started, where you use the solution you think is
which may or may not be the one I use.
That's still no different from you choosing RPM, and a developer may
only be using Debian (apt). Your platform may be stuck on a 3-4yo
version of the software with bugs, because your distro has no
maintainer for a given package.
With flatpak and appimage, your distro is supported allong with almost every major distro. With flathub, the integration is there with the software manager ui for most major distros as well (this does not
include the cli, but the graphical ui managers).
That sounds great. More complexity. More moving parts. Now I havemultiple
copies of libgtk-3 to manage and sandboxed(?) parallel installations.
And what you do not have are 3-4yo applications that are unmaintained
on the majority of distributions that break when you upgrade to the
latest version of your distribution.
Yeah, it's a little bloated, and not necessary for the most popular applications that are actively maintained on every major distro. You'd rather just not have software available for niche linux distributions
at all?
Sounds braindead if you ask me.
Well, what software are you distributing cross-platform? Are you
running a niche distribution with applications you actually *require*
that are unmaintained on your distribution of choice?
The app has all the dependencies included yes, that said, modern hard
drives are *MASSIVE* and it's better than dealing with the linux
version of DLL Hell.
So we now have multiple copies of the OS basically, and this is sold as an improvement?
You may have multiple copies/versions of common libraries, yes. You
also won't have flatpak or appimage applications break because you upgraded your distro, or deal with 4yo buggy versions of unmaintained
apps on your distro. You also won't have to deal with trying to build
all the related dependencies for a given application on your
unsupported distro.
Dennisk wrote to Gamgee <=-
I haven't had problems with dependencies for at least 10 years, and
it's "only" 10 years because I stayed on Red Hat 7.3 far longer than I should have.
That issue was solved in Linux over a decade ago. Its rare that I
can't install a Fedora package because of dependency problems.
Arelor wrote to Tracker1 <=-
Gamgee is not trying to make Linux a niche OS. And Linux has become an industrial power on its own right without a standard packaging format, which suggests to me it is actualy not such a bad big deal.
Arelor wrote to Tracker1 <=-
Gamgee is not trying to make Linux a niche OS. And Linux has become an industrial power on its own right without a standard packaging format, which suggests to me it is actualy not such a bad big deal.
I would claim that tar.gz and ./configure;make;make install is the
standard packaging format? When in doubt, you could always make from
source. Not that I'd want to for every package on my system,
although I did that with Solaris back in the 90s.
... Abandon desire
Dennisk wrote to Tracker1 <=-
flathub works across a *massive* number of distributions... as does appImage. And the problem it solves is distribution upgrades breaking applications.
Distribution upgrades rarely break programs, in my experience. I
used to not upgrade at all to prevent breakages, but a while ago
I decided to stay up to date, and update every year (Fedora
released twice a year, I catch either every update or every
second).
Despite using a distro with at least annual major-version
upgrades, I just don't see this problem, and I have many programs installed from source or installers.
No, instead of potentially something for debian, redhat, ... etc. You
can publish to an appImage, or flathub. Flatpak/flathub are available across *MANY* distributions, not just the one or two a developer may
have experience with. All dependencies are generally self contained.
Yes, but this is in ADDITION to RPM/DEB. It doesn't replace it.
So the user now has one more package type to contend with.
See, here is the problem. Developers make all these things for themselves, not for users. They think the software world
revolves around them.
No, its USERS that matter. Users use distros, and those distro's
already have systems.
Going and using (multiple) bolted-on, poorly integrated parallel installations doesn't help users.
From a developer/publisher standpoint, this means at most supporting 3 systems, not 20+.
That is true. My argument is that another package system doesn't
solve this. The only solution is agreement on a standard, and I
believe there are already existing, established working systems.
And what you do not have are 3-4yo applications that are unmaintained
on the majority of distributions that break when you upgrade to the
latest version of your distribution.
That's the beauty of linux. There is such a variety of distros, but some distros have gained more popularity based on their intended use. It's been a long time since I've had to configure or make install a program, and if I can find a distro I really like using, I wouldn't care what other distros are using as long as I have an easy to install method for the software I want.
poindexter FORTRAN wrote to Dennisk <=-
Dennisk wrote to Gamgee <=-
I haven't had problems with dependencies for at least 10 years, and
it's "only" 10 years because I stayed on Red Hat 7.3 far longer than I should have.
That issue was solved in Linux over a decade ago. Its rare that I
can't install a Fedora package because of dependency problems.
Oh, I hated the old RedHat days - this was 4.0-5.0 - lots of
dependency issues for me, admittedly I was just starting out and they
could have been pilot error, too.
Gamgee wrote to Dennisk <=-
Dennisk wrote to Tracker1 <=-
flathub works across a *massive* number of distributions... as does appImage. And the problem it solves is distribution upgrades breaking applications.
Distribution upgrades rarely break programs, in my experience. I
used to not upgrade at all to prevent breakages, but a while ago
I decided to stay up to date, and update every year (Fedora
released twice a year, I catch either every update or every
second).
Same here. As I've said in a recent post, I don't think I've
*ever* had this kind of breakage, in 20+ years.
Despite using a distro with at least annual major-version
upgrades, I just don't see this problem, and I have many programs installed from source or installers.
Ditto.
No, instead of potentially something for debian, redhat, ... etc. You
can publish to an appImage, or flathub. Flatpak/flathub are available across *MANY* distributions, not just the one or two a developer may
have experience with. All dependencies are generally self contained.
Yes, but this is in ADDITION to RPM/DEB. It doesn't replace it.
So the user now has one more package type to contend with.
See, here is the problem. Developers make all these things for themselves, not for users. They think the software world
revolves around them.
Bingo.
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
No, its USERS that matter. Users use distros, and those distro's
already have systems.
Going and using (multiple) bolted-on, poorly integrated parallel installations doesn't help users.
Agreed. Also, a "user" (not a developer) that uses a particular
distro doesn't usually give a damn as to whether an application is available/packaged for any other distros. Doesn't matter to them.
For example, as a Slackware user, I could not care less about
rpm's, or apt/yum, or whatever else is used, besides what I need.
From a developer/publisher standpoint, this means at most supporting 3 systems, not 20+.
Develop/publish the source code and let the distros worry about
packaging.
That is true. My argument is that another package system doesn't
solve this. The only solution is agreement on a standard, and I
believe there are already existing, established working systems.
Truth.
And what you do not have are 3-4yo applications that are unmaintained
on the majority of distributions that break when you upgrade to the
latest version of your distribution.
Not sure what world you're in, but that doesn't happen in my
world.
Re: Re: BBS using Vista
By: Moondog to Arelor on Thu Oct 29 2020 01:27 am
That's the beauty of linux. There is such a variety of distros, but som distros have gained more popularity based on their intended use. It's b a long time since I've had to configure or make install a program, and I can find a distro I really like using, I wouldn't care what other distros are using as long as I have an easy to install method for the software I want.
i wouldnt call it beauty. in some cases it can be a disorganized mess.
See, here is the problem. Developers make all these things forthemselves, not
for users. They think the software world revolves around them.> >No, its USERS that matter. Users use distros, and those distro's
systems.You are assuming two things... 1) developers aren't also users and 2)
Going and using (multiple) bolted-on, poorly integrated parallelinstallations
doesn't help users.Do you understand how these systems work? They aren't bolted on, though
That is,And apt and rpm aren't anything more *standard* are they? And as to
the dependencies, most of the dependencies are the same, and built in
with the kernel at this point.
No, but they are tried and tested, known, and already established.
they already exist with a long history and knowledge base. Most popular distro's have established mechanisms for dealing with these packagesin a way
that is suitable for end users.And, again... supporting Ubuntu's apt repo does fuck all for any other
solve this.With flatpak and appimage, your distro is supported allong with almost
every major distro. With flathub, the integration is there with the
software manager ui for most major distros as well (this does not
include the cli, but the graphical ui managers).
That is true. My argument is that another package system doesn't
The only solution is agreement on a standard, and I believe there arealready
existing, established working systems.What single, established, working system is in all of the top 10-20 distros?
distro. It'sYou may have multiple copies/versions of common libraries, yes. You
also won't have flatpak or appimage applications break because you
upgraded your distro, or deal with 4yo buggy versions of unmaintained
apps on your distro. You also won't have to deal with trying to build
all the related dependencies for a given application on your
unsupported distro.
If the app is not maintained, its not maintained. Regardless of
not as if making it a FlatPak automatically means that bugs in thecode get
fixed.In the case above, I'm referring to when the application is being
Gamgee is not trying to make Linux a niche OS. And Linux has become an
industrial power on its own right without a standard packaging format,
which suggests to me it is actualy not such a bad big deal.
I would claim that tar.gz and ./configure;make;make install is the
standard packaging format? When in doubt, you could always make from
source. Not that I'd want to for every package on my system,
although I did that with Solaris back in the 90s.
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
If you don't want to use appImage, flatpak or snaps, don't fucking use them... there's no need to berate those that happen to use and like
those systems.
Tracker1 wrote to Gamgee <=-
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
If you don't want to use appImage, flatpak or snaps, don't
fucking use them...
there's no need to berate those that happen
to use and like those systems.
Tracker1 wrote to Dennisk <=-
If the app is not maintained, its not maintained. Regardless of
distro. It's not as if making it a FlatPak automatically means that
bugs in the code get fixed.
In the case above, I'm referring to when the application is being maintained and upgraded, but there is nobody packaging it up for
the distro's repository.
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's
maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
If you don't want to use appImage, flatpak or snaps, don't
fucking use them...
Okay, I fucking won't.
there's no need to berate those that happen
to use and like those systems.
There's also no need to berate those who think there are already
enough "standards", and think that "the next greatest thing" is
just more....... fluff. Pffffftttttt.
If the app is not maintained, its not maintained. Regardless of
distro. It's not as if making it a FlatPak automatically means that
bugs in the code get fixed.
In the case above, I'm referring to when the application is being
maintained and upgraded, but there is nobody packaging it up for
the distro's repository.
And how often does that happen? Would I need more than one hand
to count how many applications fit that scenario?
Tracker1 wrote to Dennisk <=-
On 10/29/2020 6:43 PM, Dennisk wrote:
See, here is the problem. Developers make all these things for
themselves, not
for users. They think the software world revolves around them.> >
No, its USERS that matter. Users use distros, and those distro's
already have
systems.
You are assuming two things... 1) developers aren't also users and 2)
that those dedicating their time to open-source software should kneel before your will.
Going and using (multiple) bolted-on, poorly integrated parallel
installations
doesn't help users.
Do you understand how these systems work? They aren't bolted on,
though they do have some integration issues depending on the software.
And apt and rpm aren't anything more *standard* are they? And as to
the dependencies, most of the dependencies are the same, and built in
with the kernel at this point.
No, but they are tried and tested, known, and already established.
That is,
they already exist with a long history and knowledge base. Most popular distro's have established mechanisms for dealing with these packages
in a way
that is suitable for end users.
And, again... supporting Ubuntu's apt repo does fuck all for any other distro.
With flatpak and appimage, your distro is supported allong with almost
every major distro. With flathub, the integration is there with the
software manager ui for most major distros as well (this does not
include the cli, but the graphical ui managers).
That is true. My argument is that another package system doesn't
solve this.
The only solution is agreement on a standard, and I believe there are
already
existing, established working systems.
What single, established, working system is in all of the top 10-20 distros?
You may have multiple copies/versions of common libraries, yes. You
also won't have flatpak or appimage applications break because you
upgraded your distro, or deal with 4yo buggy versions of unmaintained
apps on your distro. You also won't have to deal with trying to build
all the related dependencies for a given application on your
unsupported distro.
If the app is not maintained, its not maintained. Regardless of
distro. It's
not as if making it a FlatPak automatically means that bugs in the
code get
fixed.
In the case above, I'm referring to when the application is being maintained and upgraded, but there is nobody packaging it up for the distro's repository.
The fact is that distro's *DONT* include a lot of software, even if the source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
On 11-04-20 16:36, Tracker1 wrote to Gamgee <=-
If it's an application you use, the count/difference is immaterial.
I've come across it more than once and running mainstream distros.
Rare. And again, the solution is staring you in the face. Package it using existing, well established tools with a long and successful history.
If it's an application you use, the count/difference is immaterial.
I've come across it more than once and running mainstream distros.
Happens a lot to me, I seem to like using applications that distro maintainers
don't include. :/
Tracker1 wrote to Dennisk <=-
Rare. And again, the solution is staring you in the face. Package it using existing, well established tools with a long and successful history.
I'll publich appimage and have it on flathub... if *YOU* want it
in *YOUR* preference of package manager, do it yourself.
On 11-05-20 16:35, Tracker1 wrote to Vk3jed <=-
Thank you... and about half the time I can get an appImage or
flatpak... flathub has made me *much* happer for most UI apps... yeah a little more disk use...but sandboxing and fewer issues while getting
the latest version.
Arelor wrote to Tracker1 <=-
Re: Re: BBS using Vista
By: Tracker1 to Gamgee on Wed Nov 04 2020 04:34 pm
The fact is that distro's *DONT* include a lot of software, even if the source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
This is why I like Slackware packaging scripts. You can create your packages very easily using script templates without dramas.
I also like OpenBSD's ports because they allow you to create your own patched versions of things automatically.
I'll publish appimage and have it on flathub... if *YOU* want it
in *YOUR* preference of package manager, do it yourself.
I'll do just that, no worries.
We'll just go ahead and put you down on the side of "change for
the sake of change". Mmmkay.
Thank you... and about half the time I can get an appImage or
flatpak... flathub has made me *much* happer for most UI apps... yeah a
little more disk use...but sandboxing and fewer issues while getting
the latest version.
I can't say I've used either of those, will have to google at some stage...
On 11/4/2020 5:56 AM, Gamgee wrote:
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's
maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
If you don't want to use appImage, flatpak or snaps, don't
fucking use them...
Okay, I fucking won't.
there's no need to berate those that happen
to use and like those systems.
There's also no need to berate those who think there are already
enough "standards", and think that "the next greatest thing" is
just more....... fluff. Pffffftttttt.
I'm not the one who went personal first in this thread.
The fact is that distro's *DONT* include a lot of software, even if the source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
--
Michael J. Ryan
tracker1 +o Roughneck BBS
On 11-06-20 12:22, Tracker1 wrote to Vk3jed <=-
Flatpak/flathub may already be there (unless Ubuntu), and easy enough
to install... once configured, results should show up mingled with your
UI application manager. Ubuntu uses Snap which is similar, but less popular outside Ubuntu (though they carry enough weight that it may be around a while itself).
On 11-06-20 21:32, Dennisk wrote to Arelor <=-
@VIA: VERT/EOTLBBS
Arelor wrote to Tracker1 <=-
Re: Re: BBS using Vista
By: Tracker1 to Gamgee on Wed Nov 04 2020 04:34 pm
The fact is that distro's *DONT* include a lot of software, even if the source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
This is why I like Slackware packaging scripts. You can create your packages very easily using script templates without dramas.
I also like OpenBSD's ports because they allow you to create your own patched versions of things automatically.
I used to use Checkinstall, which would create an RPM from a standard source package. I preferred this, but have little need for it now as I usually can find an RPM.
... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.52
= Synchronet = End Of The Line BBS - endofthelinebbs.com
Re: Re: BBS using Vista
By: Tracker1 to Gamgee on Wed Nov 04 2020 04:34 pm
On 11/4/2020 5:56 AM, Gamgee wrote:
What this guy doesn't seem to understand is that all that is
required for *ANY* distro is the source code. Then the distro's
maintainers/community can package it up they way they need it.
Seems like an actual developer would know this...
If you don't want to use appImage, flatpak or snaps, don't
fucking use them...
Okay, I fucking won't.
there's no need to berate those that happen
to use and like those systems.
There's also no need to berate those who think there are already
enough "standards", and think that "the next greatest thing" is
just more....... fluff. Pffffftttttt.
I'm not the one who went personal first in this thread.
The fact is that distro's *DONT* include a lot of software, even if the source is available. So it shouldn't be a surprise that people might want another way to get software that they want to use without having to fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical chops to do.
--
Michael J. Ryan
tracker1 +o Roughneck BBS
Depending on the purpose behind a distro, I may not want a lot of software installed. If I wanted a desktop OS, sure I would like bells and whistles. If I'm runnig a single board cumputer as a piece of instrumentation or digital
interface for a piece of equipment, I wound require just enough overhead to do the job. No need for additonal language and alternate keyboard support, an office suite, image manipulation, disc burning, or audio and video playback.
The fact is that distro's *DONT* include a lot of software, even if the
source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to
fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
Depending on the purpose behind a distro, I may not want a lot of software installed. If I wanted a desktop OS, sure I would like bells and whistles. If I'm runnig a single board cumputer as a piece of instrumentation or digital
interface for a piece of equipment, I wound require just enough overhead to do the job. No need for additonal language and alternate keyboard support, an office suite, image manipulation, disc burning, or audio and video playback.
Moondog wrote to Tracker1 <=-
Depending on the purpose behind a distro, I may not want a lot of
software installed. If I wanted a desktop OS, sure I would like bells
and whistles. If I'm runnig a single board cumputer as a piece of instrumentation or digital
On 11/6/2020 3:28 PM, Moondog wrote:
The fact is that distro's *DONT* include a lot of software, even if the >> source is available. So it shouldn't be a surprise that people might
want another way to get software that they want to use without having to >> fight the political aspects of becoming a package maintainer for a
distro they don't use, or one they do use but don't have the technical
chops to do.
Depending on the purpose behind a distro, I may not want a lot of software installed. If I wanted a desktop OS, sure I would like bells and whistles If I'm runnig a single board cumputer as a piece of instrumentation or dig
interface for a piece of equipment, I wound require just enough overhead do the job. No need for additonal language and alternate keyboard support an office suite, image manipulation, disc burning, or audio and video playback.
It can be on the distro's package repository without being installed to
the system. Most software isn't installed by default.
--
Michael J. Ryan
tracker1 +o Roughneck BBS
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 719 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 114:08:02 |
| Calls: | 9,260 |
| Calls today: | 2 |
| Files: | 5,288 |
| Messages: | 466,734 |