Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-10 > #181294 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2025-01-12 23:23 +0000 |
| Last post | 2025-01-16 11:35 -0500 |
| Articles | 20 on this page of 102 — 23 participants |
Back to article view | Back to alt.comp.os.windows-10
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-12 23:23 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs MikeS <MikeS@fred.com> - 2025-01-13 21:25 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-13 16:32 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs CrudeSausage <crude@sausa.ge> - 2025-01-13 17:44 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-13 17:54 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs CrudeSausage <crude@sausa.ge> - 2025-01-13 18:10 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-13 18:25 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Hank Rogers <Hank@nospam.invalid> - 2025-01-13 17:52 -0600
Cult of Unix (was: Re: Microsoft to force new Outlook on Windows 10 PCs) vallor <vallor@cultnix.org> - 2025-01-15 00:30 +0000
Re: Cult of Unix Hank Rogers <Hank@nospam.invalid> - 2025-01-14 20:05 -0600
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-15 03:16 -0500
Re: Cult of Unix vallor <vallor@cultnix.org> - 2025-01-15 09:02 +0000
Re: Cult of Unix ...w¡ñ§±¤ñ <winstonmvp@gmail.com> - 2025-01-15 11:10 -0700
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-16 05:03 +0000
Re: 🏳️🌈Cult of Unix🏳️🌈 🌈💐🌻🌺🌹🌻💐🌷🌺🌈Jen🌈💐🌻🌺🌹🌻💐🌷🌺🌈 Dershmender 💐🌻🌺🌹🌻💐🌷🌺🐶笛🌈💐🌻🌺🌹🌻💐🌷🌺🌈 <root@127.0.0.1> - 2025-01-16 05:28 +0000
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-16 10:34 -0500
Re: Cult of Unix vallor <vallor@cultnix.org> - 2025-01-16 16:04 +0000
Re: Cult of Unix Hank Rogers <Hank@nospam.invalid> - 2025-01-16 14:48 -0600
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-16 18:06 -0500
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 02:49 +0000
Re: Cult of Unix vallor <vallor@cultnix.org> - 2025-01-17 03:51 +0000
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-17 02:10 -0500
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 23:55 +0000
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-17 20:53 -0500
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-19 00:54 +0000
Re: Cult of Unix Frank Slootweg <this@ddress.is.invalid> - 2025-01-17 16:46 +0000
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 23:56 +0000
Re: Cult of Unix Paul <nospam@needed.invalid> - 2025-01-17 20:54 -0500
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-19 00:55 +0000
Re: Cult of Unix Joel <joelcrump@gmail.com> - 2025-01-18 20:01 -0500
Re: Cult of Unix Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 00:10 +0000
Re: 🏳️🌈Cult of Unix (was: Re: Microsoft to force new Outlook on Windows 10 PCs)🏳️🌈 🌈💐🌻🌺🌹🌻💐🌷🌺🌈Jen🌈💐🌻🌺🌹🌻💐🌷🌺🌈 Dershmender 💐🌻🌺🌹🌻💐🌷🌺🐶笛🌈💐🌻🌺🌹🌻💐🌷🌺🌈 <root@127.0.0.1> - 2025-01-15 05:24 +0000
Setting up old-style backup on Windows 11 (was: Re: Cult of Unix) vallor <vallor@cultnix.org> - 2025-01-15 08:38 +0000
Re: 🏳️🌈Setting up old-style backup on Windows 11 (was: Re: Cult of Unix)🏳️🌈 🌈💐🌻🌺🌹🌻💐🌷🌺🌈Jen🌈💐🌻🌺🌹🌻💐🌷🌺🌈 Dershmender 💐🌻🌺🌹🌻💐🌷🌺🐶笛🌈💐🌻🌺🌹🌻💐🌷🌺🌈 <root@127.0.0.1> - 2025-01-15 17:22 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs CrudeSausage <crude@sausa.ge> - 2025-01-13 21:44 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Manu Raju <MR@invalid.invalid> - 2025-01-14 03:09 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-15 06:56 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-15 02:52 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 00:11 +0000
Defragging (was: Re: Microsoft to force new Outlook on Windows 10 PCs) vallor <vallor@cultnix.org> - 2025-01-17 03:45 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-17 23:10 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-15 10:40 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs rbowman <bowman@montana.com> - 2025-01-15 23:14 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-15 20:15 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs pothead <pothead@snakebite.com> - 2025-01-16 01:29 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-14 12:46 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs "Carlos E.R." <robin_listas@es.invalid> - 2025-01-15 13:51 +0100
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-15 09:58 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs "Carlos E.R." <robin_listas@es.invalid> - 2025-01-15 16:20 +0100
Re: Microsoft to force new Outlook on Windows 10 PCs rbowman <bowman@montana.com> - 2025-01-15 23:20 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs "Carlos E.R." <robin_listas@es.invalid> - 2025-01-16 15:36 +0100
Re: Microsoft to force new Outlook on Windows 10 PCs rbowman <bowman@montana.com> - 2025-01-17 00:12 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Chris <ithinkiam@gmail.com> - 2025-01-15 18:09 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs "Carlos E.R." <robin_listas@es.invalid> - 2025-01-16 15:47 +0100
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-14 05:48 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Hank Rogers <Hank@nospam.invalid> - 2025-01-13 16:48 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs rbowman <bowman@montana.com> - 2025-01-13 23:54 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Chris <ithinkiam@gmail.com> - 2025-01-15 11:33 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-15 10:46 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-15 11:33 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs vallor <vallor@cultnix.org> - 2025-01-15 17:02 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-16 05:40 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 06:27 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-27 22:49 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-15 14:32 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-15 15:52 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-15 20:34 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 00:41 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 06:42 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 14:40 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 16:34 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 16:56 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 22:40 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-17 02:04 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs chrisv <chrisv@nospam.invalid> - 2025-01-17 07:34 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs roger <rduffy@hotmail.com.invalid - 2025-01-17 14:01 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-17 15:57 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-17 16:50 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-17 21:52 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Farley Flud <ff@linux.rocks> - 2025-01-16 21:38 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 15:44 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 15:51 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-16 16:11 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs Farley Flud <fsquared@fsquared.linux> - 2025-01-17 13:03 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-17 16:00 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs Farley Flud <ff@linux.rocks> - 2025-01-17 23:15 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-17 18:10 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs Physfitfreak <physfitfreak@gmail.com> - 2025-01-17 18:13 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 06:22 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-16 12:10 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs chrisv <chrisv@nospam.invalid> - 2025-01-16 12:28 -0600
Re: Microsoft to force new Outlook on Windows 10 PCs rbowman <bowman@montana.com> - 2025-01-17 00:27 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Paul <nospam@needed.invalid> - 2025-01-16 23:47 -0500
Gaming Laptops (was: Re: Microsoft to force new Outlook on Windows 10 PCs) vallor <vallor@cultnix.org> - 2025-02-01 12:58 +0000
Re: Gaming Laptops Paul <nospam@needed.invalid> - 2025-02-01 19:22 -0500
Re: Gaming Laptops chrisv <chrisv@nospam.invalid> - 2025-02-02 08:05 -0600
Re: Gaming Laptops candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-02-03 20:10 +0000
Re: Gaming Laptops Paul <nospam@needed.invalid> - 2025-02-03 19:24 -0500
Re: Gaming Laptops pothead <pothead@snakebite.com> - 2025-02-04 00:45 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs Mark Lloyd <not.email@all.invalid> - 2025-01-16 18:45 +0000
Re: Microsoft to force new Outlook on Windows 10 PCs -hh <recscuba_google@huntzinger.com> - 2025-01-16 16:05 -0500
Re: Microsoft to force new Outlook on Windows 10 PCs Joel <joelcrump@gmail.com> - 2025-01-16 11:35 -0500
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-01-17 23:10 +0000 |
| Message-ID | <vmeo0h$9hcv$3@dont-email.me> |
| In reply to | #181474 |
Never had to use a defragger on Linux, and likely never will.
[toc] | [prev] | [next] | [standalone]
| From | Joel <joelcrump@gmail.com> |
|---|---|
| Date | 2025-01-15 10:40 -0500 |
| Message-ID | <2jlfoj1ik2eptf57n2vtpfcsjhnmjc2pd8@4ax.com> |
| In reply to | #181353 |
Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >On Tue, 14 Jan 2025 03:09:43 +0000, Manu Raju wrote: > >> Linux gets bloats every two weeks >> and some people like it! I don't and so I solved the dilemma by moving >> to Windows. > >Windows is the one that needs regular defragging and running of dodgy >hacks like CCleaner etc. Linux does not. I never needed that with Windows, but reinstalling ended up happening, from time to time. -- Joel W. Crump Amendment XIV Section 1. [...] No state shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any state deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws. Dobbs rewrites this, it is invalid precedent. States are liable for denying needed abortions, e.g. TX.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-01-15 23:14 +0000 |
| Message-ID | <luqtrgFijddU4@mid.individual.net> |
| In reply to | #181372 |
On Wed, 15 Jan 2025 10:40:14 -0500, Joel wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >>On Tue, 14 Jan 2025 03:09:43 +0000, Manu Raju wrote: >> >>> Linux gets bloats every two weeks and some people like it! I don't >>> and so I solved the dilemma by moving to Windows. >> >>Windows is the one that needs regular defragging and running of dodgy >>hacks like CCleaner etc. Linux does not. > > > I never needed that with Windows, but reinstalling ended up happening, > from time to time. I haven't bothered with dual boot in a long time but the problem with a Windows install that had been running for any length of time was it left pecker tracks all over the HDD. You had to defrag to get enough free storage all in one place.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-01-15 20:15 -0500 |
| Message-ID | <vm9mk9$36phj$1@dont-email.me> |
| In reply to | #181394 |
On Wed, 1/15/2025 6:14 PM, rbowman wrote:
> On Wed, 15 Jan 2025 10:40:14 -0500, Joel wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 14 Jan 2025 03:09:43 +0000, Manu Raju wrote:
>>>
>>>> Linux gets bloats every two weeks and some people like it! I don't
>>>> and so I solved the dilemma by moving to Windows.
>>>
>>> Windows is the one that needs regular defragging and running of dodgy
>>> hacks like CCleaner etc. Linux does not.
>>
>>
>> I never needed that with Windows, but reinstalling ended up happening,
>> from time to time.
>
> I haven't bothered with dual boot in a long time but the problem with a
> Windows install that had been running for any length of time was it left
> pecker tracks all over the HDD. You had to defrag to get enough free
> storage all in one place.
>
Not in evidence.
The writer tends to maintain a couple of zones. Some
of the larger files seem to end up above, a lot of the smaller files
are below. The NTFS file system has a "reserved" area, which
interferes with operation of the partition, as the partition fills up.
This is why, quite frequently, patterns which should not create fragments,
result in "yellow" in a partition that should not have been there. The
reserved area starts at a certain size, and the amount of reservation
changes as the space fills up. For people who like their files packed
like sardines, they are most put out by this development :-)
[Picture]
https://i.postimg.cc/YCDLWmkB/Windows-SSD-fragmentation.gif
These sample OSes are all on SSDs, where the rule is, you do not defragment them.
(SSDs get TRIM, instead.) The OS still has the right to defragment them,
if slow-COW conditions are detected. That should not have happened to these.
The top two panes are from a newer AMD system. The bottom two panes
are from the 4930K ten year old computer.
The "red line" is an item that cannot be moved by the defragmentation
tool used to make these pictures. I use the tool for taking pictures,
when these particular devices are involved. The fragmentation means
nothing (at this light level of fragmentation) to performance.
The "red line" can also not be moved by the windows Disk Management
"shrink function". It can shrink to about 50% of the original partition
space, when a partition does not have a lot of files. In the "red line example"
at the bottom, the Disk Management will shrink to 50%, while other methods
will shrink to 33% or so. The shrinking process stops when it hits
that red line.
Generally, if the program doing the shrink is doing it in an offline
fashion, that gives much better control than when the Windows one attempts
to do it online ("hot" shrink). Thus, gparted can shrink the red line pane,
to the 33% number without too much delay.
It's the same with zeroing functions. The Windows third party tool is
"sdelete64.exe" and it zeros a partition while the partition remains
mounted. Whereas Linux "zerofree" does this same kind of function
on unmounted partitions.
One reason the Windows people like to show off with their
functions such as shrink, is they're implemented with the
data-safe defragmenter API. Which was originally written
by a third party, but was good enough for Microsoft to buy
it and put it in the OS as a library. Everybody and his dog
uses that library. It would be "extra work" for somebody
to write an offline version of the tool instead :-) The tool
that took the green pictures, also uses that library.
There's still plenty of room to work on those partitions.
On this sample data partition, this shows how the writer
is filling in the holes, and the two "air holes" are likely
a result of the reserved space handling. Again, being on an
SSD, no attempt has ever been made to defragment the thing.
And the green, is files which are contiguous and their
clusters are in cluster-order. The yellow ones are "largely ordered",
but as soon as one cluster goes out of line for such a file,
the whole file will be yellow. Considering "how evil" fragmentation
is, you don't see a lot of fragmentation there.
[Picture]
https://i.postimg.cc/wjRgwtLp/Sample-Data-Partition.gif
*******
This picture was done seven years ago. The top two panes are
performance on a RAMdrive. Running a checksum program on
a large file, one with a lot of fragments, one with no fragments,
there is hardly any speed difference to the performance of the
checksum program when we are measuring the file system stack
penalty for fragments.
[Picture} Top two panes = RAMDrive, bottom two panes = SATA SSD
https://i.postimg.cc/ry7VnwF7/fragmentation.gif
Whereas the bottom case, the seek time on an SSD could be 20 microseconds
or so. And then the SSD speed does have an impact on the read rate of
the checksumming process. When doing these experiments, you do a bit of
fiddling first to clear the System Read cache.
No attempt was made to run that on a HDD, as the results would
be quite bad on an HDD. The rattling noise that would make, would
get on my nerves.
And the pattern on the storage there, was done with a purpose-built
pathological tool. I wasn't doing my income taxes to make that pattern.
Regular disk usage does not fragment like that.
Is Windows cheating to make relatively good-looking partitions ?
It's possible. I do not normally see suspicious patterns of the
drive light, hinting that some rearranging is going on. The write
algo has changed since WinXP days, whatever it is. Leaving holes
in the cheese, seems to have something to do with later placing
small files in the holes.
Paul
[toc] | [prev] | [next] | [standalone]
| From | pothead <pothead@snakebite.com> |
|---|---|
| Date | 2025-01-16 01:29 +0000 |
| Message-ID | <vm9nef$36t0s$1@dont-email.me> |
| In reply to | #181396 |
On 2025-01-16, Paul <nospam@needed.invalid> wrote:
> On Wed, 1/15/2025 6:14 PM, rbowman wrote:
>> On Wed, 15 Jan 2025 10:40:14 -0500, Joel wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Tue, 14 Jan 2025 03:09:43 +0000, Manu Raju wrote:
>>>>
>>>>> Linux gets bloats every two weeks and some people like it! I don't
>>>>> and so I solved the dilemma by moving to Windows.
>>>>
>>>> Windows is the one that needs regular defragging and running of dodgy
>>>> hacks like CCleaner etc. Linux does not.
>>>
>>>
>>> I never needed that with Windows, but reinstalling ended up happening,
>>> from time to time.
>>
>> I haven't bothered with dual boot in a long time but the problem with a
>> Windows install that had been running for any length of time was it left
>> pecker tracks all over the HDD. You had to defrag to get enough free
>> storage all in one place.
>>
>
> Not in evidence.
>
> The writer tends to maintain a couple of zones. Some
> of the larger files seem to end up above, a lot of the smaller files
> are below. The NTFS file system has a "reserved" area, which
> interferes with operation of the partition, as the partition fills up.
> This is why, quite frequently, patterns which should not create fragments,
> result in "yellow" in a partition that should not have been there. The
> reserved area starts at a certain size, and the amount of reservation
> changes as the space fills up. For people who like their files packed
> like sardines, they are most put out by this development :-)
>
> [Picture]
>
> https://i.postimg.cc/YCDLWmkB/Windows-SSD-fragmentation.gif
>
> These sample OSes are all on SSDs, where the rule is, you do not defragment them.
> (SSDs get TRIM, instead.) The OS still has the right to defragment them,
> if slow-COW conditions are detected. That should not have happened to these.
>
> The top two panes are from a newer AMD system. The bottom two panes
> are from the 4930K ten year old computer.
>
> The "red line" is an item that cannot be moved by the defragmentation
> tool used to make these pictures. I use the tool for taking pictures,
> when these particular devices are involved. The fragmentation means
> nothing (at this light level of fragmentation) to performance.
>
> The "red line" can also not be moved by the windows Disk Management
> "shrink function". It can shrink to about 50% of the original partition
> space, when a partition does not have a lot of files. In the "red line example"
> at the bottom, the Disk Management will shrink to 50%, while other methods
> will shrink to 33% or so. The shrinking process stops when it hits
> that red line.
>
> Generally, if the program doing the shrink is doing it in an offline
> fashion, that gives much better control than when the Windows one attempts
> to do it online ("hot" shrink). Thus, gparted can shrink the red line pane,
> to the 33% number without too much delay.
>
> It's the same with zeroing functions. The Windows third party tool is
> "sdelete64.exe" and it zeros a partition while the partition remains
> mounted. Whereas Linux "zerofree" does this same kind of function
> on unmounted partitions.
>
> One reason the Windows people like to show off with their
> functions such as shrink, is they're implemented with the
> data-safe defragmenter API. Which was originally written
> by a third party, but was good enough for Microsoft to buy
> it and put it in the OS as a library. Everybody and his dog
> uses that library. It would be "extra work" for somebody
> to write an offline version of the tool instead :-) The tool
> that took the green pictures, also uses that library.
>
> There's still plenty of room to work on those partitions.
>
> On this sample data partition, this shows how the writer
> is filling in the holes, and the two "air holes" are likely
> a result of the reserved space handling. Again, being on an
> SSD, no attempt has ever been made to defragment the thing.
> And the green, is files which are contiguous and their
> clusters are in cluster-order. The yellow ones are "largely ordered",
> but as soon as one cluster goes out of line for such a file,
> the whole file will be yellow. Considering "how evil" fragmentation
> is, you don't see a lot of fragmentation there.
>
> [Picture]
>
> https://i.postimg.cc/wjRgwtLp/Sample-Data-Partition.gif
>
> *******
>
> This picture was done seven years ago. The top two panes are
> performance on a RAMdrive. Running a checksum program on
> a large file, one with a lot of fragments, one with no fragments,
> there is hardly any speed difference to the performance of the
> checksum program when we are measuring the file system stack
> penalty for fragments.
>
> [Picture} Top two panes = RAMDrive, bottom two panes = SATA SSD
>
> https://i.postimg.cc/ry7VnwF7/fragmentation.gif
>
> Whereas the bottom case, the seek time on an SSD could be 20 microseconds
> or so. And then the SSD speed does have an impact on the read rate of
> the checksumming process. When doing these experiments, you do a bit of
> fiddling first to clear the System Read cache.
>
> No attempt was made to run that on a HDD, as the results would
> be quite bad on an HDD. The rattling noise that would make, would
> get on my nerves.
>
> And the pattern on the storage there, was done with a purpose-built
> pathological tool. I wasn't doing my income taxes to make that pattern.
> Regular disk usage does not fragment like that.
>
> Is Windows cheating to make relatively good-looking partitions ?
> It's possible. I do not normally see suspicious patterns of the
> drive light, hinting that some rearranging is going on. The write
> algo has changed since WinXP days, whatever it is. Leaving holes
> in the cheese, seems to have something to do with later placing
> small files in the holes.
>
> Paul
Enjoy your posts Paul.
Just sayin'.
--
pothead
"Give a man a fish and you turn him into a Democrat for life"
"Teach a man to fish and he might become a self-sufficient conservative Republican"
"Don't underestimate Joe's ability to fuck things up,"
--- Barack H. Obama
[toc] | [prev] | [next] | [standalone]
| From | -hh <recscuba_google@huntzinger.com> |
|---|---|
| Date | 2025-01-14 12:46 -0500 |
| Message-ID | <vm67t6$2gq6u$2@dont-email.me> |
| In reply to | #181320 |
On 1/13/25 6:10 PM, CrudeSausage wrote: > On 2025-01-13 17:54, Joel wrote: >> CrudeSausage <crude@sausa.ge> wrote: >>> On 2025-01-13 16:32, Joel wrote: >>>> MikeS <MikeS@fred.com> wrote: >>>>> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>>>>> >>>>>> Windows is a great OS -- if your time is worth >>>>>> nothing. >>>>>> >>>>> So which OS do you choose to expend your valuable time on? >>>> >>>> Linux is the only option worth pursuing. macOS is weird and >>>> expensive, Windows is bloatware beyond belief. >>> >>> There's not much to pursue in MacOS. It works as it should and it is a >>> fairly pleasant experience. However, I would agree that it's expensive. >>> After a while, you'll need tools to do additional things and on MacOS, >>> you're going to be paying money in most cases. Open-source is available >>> for it too, mind you. >> >> >> I just dislike Windows and macOS, it might be my own opinion but it's >> right for me. > > MacOS machines have a shelf life of about seven years before Apple > decides that your machine is no longer worth supporting with updates. As > we've seen, Windows machines get about seven, so it's a fair amount of > time. However, Linux has them both beat with unlimited support no matter > how pathetic the machine you're running it on is. Fair points ... although it can also be worth mentioning that it typically takes Linux awhile to get around to supporting the newest gear, so its more along the lines of instead of support for Year 0 through Year 7, its more akin to support for Year ~3 to Year 15. -hh
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-01-15 13:51 +0100 |
| Message-ID | <sink5lx0bu.ln2@Telcontar.valinor> |
| In reply to | #181320 |
On 2025-01-14 00:10, CrudeSausage wrote: > On 2025-01-13 17:54, Joel wrote: >> CrudeSausage <crude@sausa.ge> wrote: >>> On 2025-01-13 16:32, Joel wrote: >>>> MikeS <MikeS@fred.com> wrote: >>>>> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>>>>> >>>>>> Windows is a great OS -- if your time is worth >>>>>> nothing. >>>>>> >>>>> So which OS do you choose to expend your valuable time on? >>>> >>>> Linux is the only option worth pursuing. macOS is weird and >>>> expensive, Windows is bloatware beyond belief. >>> >>> There's not much to pursue in MacOS. It works as it should and it is a >>> fairly pleasant experience. However, I would agree that it's expensive. >>> After a while, you'll need tools to do additional things and on MacOS, >>> you're going to be paying money in most cases. Open-source is available >>> for it too, mind you. >> >> >> I just dislike Windows and macOS, it might be my own opinion but it's >> right for me. > > MacOS machines have a shelf life of about seven years before Apple > decides that your machine is no longer worth supporting with updates. As > we've seen, Windows machines get about seven, so it's a fair amount of > time. However, Linux has them both beat with unlimited support no matter > how pathetic the machine you're running it on is. Hum. That is not completely true, either. Some distributions stopped supporting 32 bit machines. Each year you need more ram to run the same apps. Proprietary drivers like NVidia stop publishing drivers for what they think is old hardware, and the open source version doesn't have the full feature set. Modern videos use codecs that can not keep running fast enough on pathetic machines. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-01-15 09:58 -0500 |
| Message-ID | <vm8if5$30666$1@dont-email.me> |
| In reply to | #181368 |
On Wed, 1/15/2025 7:51 AM, Carlos E.R. wrote:
> On 2025-01-14 00:10, CrudeSausage wrote:
>> MacOS machines have a shelf life of about seven years before Apple decides that your machine is no longer worth supporting with updates. As we've seen, Windows machines get about seven, so it's a fair amount of time. However, Linux has them both beat with unlimited support no matter how pathetic the machine you're running it on is.
>
> Hum. That is not completely true, either. Some distributions stopped supporting 32 bit machines.
>
> Each year you need more ram to run the same apps.
>
> Proprietary drivers like NVidia stop publishing drivers for what they think is old hardware, and the open source version doesn't have the full feature set.
>
> Modern videos use codecs that can not keep running fast enough on pathetic machines.
As long as the videos are coded in something that VAAPI or NVENC/NVDEC has,
the movie can be decoded for "almost free". For example, Intel Quicksync
has sufficient horsepower, to decode five video streams at the same time,
on the early instances of that hardware block.
Old machines and their older video cards without NVidia driver support, might no
longer have access to the built-in encoder/decoder hardware on the video card,
in which case the fallback software method would be used instead.
Another contributor to "pathetic", is the video decoding process can use a
"scaler" which changes a 720x576 decoded video, to whatever box size the
browser presents at the time (the wrapper frame). Doing a pixmap scaler
in software, used at least 30% of a P4 core. Whereas the hardware scaler
(driver support), could do a scaling operation "for free".
And finally, insisting on compositing as a system-wide way of doing things,
if the video card compositing is not working and the OS has to use fallback
code for that, that could take buckets of horsepower to do.
An old machine really needs the support. It isn't so much "pathetic" as it is
everything working against it. "All the items are leaning the wrong way."
The code path has had IDCT removed, so when an old machine has been
stripped of all its goodness, the code doesn't even use the IDCT
(Inverse Discrete Cosine transform for macroblocks). That is a method of
providing a slight acceleration, when forced to do video decode in software.
The older software used to use that, as it helped a bit with the decoding
process.
Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-01-15 16:20 +0100 |
| Message-ID | <2b0l5lxdo.ln2@Telcontar.valinor> |
| In reply to | #181370 |
On 2025-01-15 15:58, Paul wrote:
> On Wed, 1/15/2025 7:51 AM, Carlos E.R. wrote:
>> On 2025-01-14 00:10, CrudeSausage wrote:
>>> MacOS machines have a shelf life of about seven years before Apple decides that your machine is no longer worth supporting with updates. As we've seen, Windows machines get about seven, so it's a fair amount of time. However, Linux has them both beat with unlimited support no matter how pathetic the machine you're running it on is.
>>
>> Hum. That is not completely true, either. Some distributions stopped supporting 32 bit machines.
>>
>> Each year you need more ram to run the same apps.
>>
>> Proprietary drivers like NVidia stop publishing drivers for what they think is old hardware, and the open source version doesn't have the full feature set.
>>
>> Modern videos use codecs that can not keep running fast enough on pathetic machines.
>
> As long as the videos are coded in something that VAAPI or NVENC/NVDEC has,
> the movie can be decoded for "almost free". For example, Intel Quicksync
> has sufficient horsepower, to decode five video streams at the same time,
> on the early instances of that hardware block.
>
> Old machines and their older video cards without NVidia driver support, might no
> longer have access to the built-in encoder/decoder hardware on the video card,
> in which case the fallback software method would be used instead.
>
> Another contributor to "pathetic", is the video decoding process can use a
> "scaler" which changes a 720x576 decoded video, to whatever box size the
> browser presents at the time (the wrapper frame). Doing a pixmap scaler
> in software, used at least 30% of a P4 core. Whereas the hardware scaler
> (driver support), could do a scaling operation "for free".
>
> And finally, insisting on compositing as a system-wide way of doing things,
> if the video card compositing is not working and the OS has to use fallback
> code for that, that could take buckets of horsepower to do.
>
> An old machine really needs the support. It isn't so much "pathetic" as it is
> everything working against it. "All the items are leaning the wrong way."
>
> The code path has had IDCT removed, so when an old machine has been
> stripped of all its goodness, the code doesn't even use the IDCT
> (Inverse Discrete Cosine transform for macroblocks). That is a method of
> providing a slight acceleration, when forced to do video decode in software.
> The older software used to use that, as it helped a bit with the decoding
> process.
Right.
I have a mini PC that I use as server and to display movies in my computer room.
Isengard:~ # inxi -GSaz --vs
inxi 3.3.23-00 (2022-10-31)
System:
Kernel: 5.14.21-150500.55.88-default arch: x86_64 bits: 64 compiler: gcc
v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.88-default
root=UUID=0d457df1-b43d-4587-aa5a-6c919bcbedb8 showopts splash=verbose
resume=/dev/disk/by-label/Swap verbose mitigations=auto
Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.34 info: xfce4-panel wm: xfwm
v: 4.18.0 dm: SDDM Distro: openSUSE Leap 15.5
Graphics:
Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx
Integrated Graphics vendor: Micro-Star MSI driver: i915 v: kernel
arch: Gen-8 process: Intel 14nm built: 2014-15 ports: active: HDMI-A-3
empty: DP-1, DP-2, DP-3, HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0
chip-ID: 8086:22b1 class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5
compositor: xfwm v: 4.18.0 driver: X: loaded: intel dri: iris gpu: i915
display-ID: localhost:11.0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: HDMI-A-3 mapped: DVI-D-0 model: Samsung T22C350 built: 2012
res: 1920x1080 hz: 60 dpi: 92 gamma: 1.2 size: 531x298mm (20.91x11.73")
diag: 547mm (21.5") ratio: 16:9 modes: max: 1920x1080 min: 720x400
API: OpenGL v: 4.5 Mesa 22.3.5 renderer: llvmpipe (LLVM 15.0.7 128 bits)
direct render: Yes
Isengard:~ #
Well, there are movies that simply block, display one photo then get stuck. Maybe the audio keeps playing. I had to recode with ffmpeg on another machine in order to view them here.
YouTube, I can no longer display in full screen, because the image stutters. I can see the CPU load at about 90%.
--
Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-01-15 23:20 +0000 |
| Message-ID | <luqu6fFijddU5@mid.individual.net> |
| In reply to | #181368 |
On Wed, 15 Jan 2025 13:51:08 +0100, Carlos E.R. wrote: > Hum. That is not completely true, either. Some distributions stopped > supporting 32 bit machines. The only one I came across was Debian. The machine itself was 64-bit but our legacy code was 32-bit, as was Esri's ArcObjects. I think Ubuntu 18.04 was the last release where you had a prayer of finding 32-bit Motif libraries and others. It's all fine to pass the 32-bit flag to gcc but if you can't link the libs you're done.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-01-16 15:36 +0100 |
| Message-ID | <j4in5lxkp3.ln2@Telcontar.valinor> |
| In reply to | #181395 |
On 2025-01-16 00:20, rbowman wrote: > On Wed, 15 Jan 2025 13:51:08 +0100, Carlos E.R. wrote: > >> Hum. That is not completely true, either. Some distributions stopped >> supporting 32 bit machines. > > The only one I came across was Debian. The machine itself was 64-bit but > our legacy code was 32-bit, as was Esri's ArcObjects. I think Ubuntu 18.04 > was the last release where you had a prayer of finding 32-bit Motif > libraries and others. It's all fine to pass the 32-bit flag to gcc but if > you can't link the libs you're done. openSUSE Tumbleweed still has a 32 bit version, I believe. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-01-17 00:12 +0000 |
| Message-ID | <lutlirF1tatU2@mid.individual.net> |
| In reply to | #181421 |
On Thu, 16 Jan 2025 15:36:35 +0100, Carlos E.R. wrote: > On 2025-01-16 00:20, rbowman wrote: >> On Wed, 15 Jan 2025 13:51:08 +0100, Carlos E.R. wrote: >> >>> Hum. That is not completely true, either. Some distributions stopped >>> supporting 32 bit machines. >> >> The only one I came across was Debian. The machine itself was 64-bit >> but our legacy code was 32-bit, as was Esri's ArcObjects. I think >> Ubuntu 18.04 was the last release where you had a prayer of finding >> 32-bit Motif libraries and others. It's all fine to pass the 32-bit >> flag to gcc but if you can't link the libs you're done. > > openSUSE Tumbleweed still has a 32 bit version, I believe. So it does. I don't know if I'd found it or if Debian was the first to turn up and I used it. I probably still would have went with Debian. For a production machine old, slow, stick-in-the-mud is good versus a rolling distribution.
[toc] | [prev] | [next] | [standalone]
| From | Chris <ithinkiam@gmail.com> |
|---|---|
| Date | 2025-01-15 18:09 +0000 |
| Message-ID | <vm8tln$326m7$1@dont-email.me> |
| In reply to | #181320 |
CrudeSausage <crude@sausa.ge> wrote: > On 2025-01-13 17:54, Joel wrote: >> CrudeSausage <crude@sausa.ge> wrote: >>> On 2025-01-13 16:32, Joel wrote: >>>> MikeS <MikeS@fred.com> wrote: >>>>> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>>>>> >>>>>> Windows is a great OS -- if your time is worth >>>>>> nothing. >>>>>> >>>>> So which OS do you choose to expend your valuable time on? >>>> >>>> Linux is the only option worth pursuing. macOS is weird and >>>> expensive, Windows is bloatware beyond belief. >>> >>> There's not much to pursue in MacOS. It works as it should and it is a >>> fairly pleasant experience. However, I would agree that it's expensive. >>> After a while, you'll need tools to do additional things and on MacOS, >>> you're going to be paying money in most cases. Open-source is available >>> for it too, mind you. >> >> >> I just dislike Windows and macOS, it might be my own opinion but it's >> right for me. > > MacOS machines have a shelf life of about seven years before Apple > decides that your machine is no longer worth supporting with updates. As > we've seen, Windows machines get about seven, so it's a fair amount of > time. However, Linux has them both beat with unlimited support no matter > how pathetic the machine you're running it on is. Only if you're prepared to handroll backports etc. Realistically, linux is also 5-7 years. Most LTS is 5 years. The hardest thing is trying to keep gcc up to date. At some point too many glibc dependencies break and you can't compile any new kernel updates.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-01-16 15:47 +0100 |
| Message-ID | <7pin5lxif5.ln2@Telcontar.valinor> |
| In reply to | #181383 |
On 2025-01-15 19:09, Chris wrote: > CrudeSausage <crude@sausa.ge> wrote: >> On 2025-01-13 17:54, Joel wrote: >>> CrudeSausage <crude@sausa.ge> wrote: >>>> On 2025-01-13 16:32, Joel wrote: >>>>> MikeS <MikeS@fred.com> wrote: >>>>>> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>>>>>> >>>>>>> Windows is a great OS -- if your time is worth >>>>>>> nothing. >>>>>>> >>>>>> So which OS do you choose to expend your valuable time on? >>>>> >>>>> Linux is the only option worth pursuing. macOS is weird and >>>>> expensive, Windows is bloatware beyond belief. >>>> >>>> There's not much to pursue in MacOS. It works as it should and it is a >>>> fairly pleasant experience. However, I would agree that it's expensive. >>>> After a while, you'll need tools to do additional things and on MacOS, >>>> you're going to be paying money in most cases. Open-source is available >>>> for it too, mind you. >>> >>> >>> I just dislike Windows and macOS, it might be my own opinion but it's >>> right for me. >> >> MacOS machines have a shelf life of about seven years before Apple >> decides that your machine is no longer worth supporting with updates. As >> we've seen, Windows machines get about seven, so it's a fair amount of >> time. However, Linux has them both beat with unlimited support no matter >> how pathetic the machine you're running it on is. > > Only if you're prepared to handroll backports etc. Realistically, linux is > also 5-7 years. Most LTS is 5 years. > > The hardest thing is trying to keep gcc up to date. At some point too many > glibc dependencies break and you can't compile any new kernel updates. No, the idea is that you upgrade the system. Thus you continue using Linux for many years on the same machine. For example, on openSUSE Leap the 15.x series started with 15.0 on 2018-05, and 15.6 was released on 2024-06. Users are expected to update to each minor version as they are released. Major version 16.0 is expected by next November. There are no hard hardware requirements to upgrade, like having TPM, but a 32 bit CPU is not supported, and possibly some low end CPUs. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-01-14 05:48 +0000 |
| Message-ID | <vm4ts0$29sf3$1@dont-email.me> |
| In reply to | #181314 |
On Mon, 13 Jan 2025 17:44:54 -0500, CrudeSausage wrote: > There's not much to pursue in MacOS. It works as it should and it is a > fairly pleasant experience. It works the way the platform owner wants it to work. And they have a particularly slick brainw^H^H^H^H^H^Hmarketing organization to “persuade” customers to accept that they want it to work that way as well.
[toc] | [prev] | [next] | [standalone]
| From | Hank Rogers <Hank@nospam.invalid> |
|---|---|
| Date | 2025-01-13 16:48 -0600 |
| Message-ID | <vm4574$22ghg$3@dont-email.me> |
| In reply to | #181311 |
Joel wrote: > MikeS <MikeS@fred.com> wrote: >> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>> On Fri, 10 Jan 2025 12:37:00 -0500, CrudeSausage wrote: >>> >>>> To remove the new Outlook app package after it's force installed on your >>>> Windows device, you can use the Remove-AppxProvisionedPackage cmdlet >>>> with the PackageName parameter value Microsoft.OutlookForWindows. >>>> >>>> This can be done by running the following command from a Windows >>>> PowerShell prompt and adding a new reg value: >>>> >>>> [Blah blah hoyvin-glayvin blah blah] >>> >>> This is why they say, Windows is a great OS -- if your time is worth >>> nothing. >>> >> So which OS do you choose to expend your valuable time on? > > > Linux is the only option worth pursuing. macOS is weird and > expensive, Windows is bloatware beyond belief. > I agree. Plus it also counts as a religion, so you don't have to waste time going to church anymore.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-01-13 23:54 +0000 |
| Message-ID | <lulnd2Flv1jU7@mid.individual.net> |
| In reply to | #181316 |
On Mon, 13 Jan 2025 16:48:03 -0600, Hank Rogers wrote: > Joel wrote: >> MikeS <MikeS@fred.com> wrote: >>> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>>> On Fri, 10 Jan 2025 12:37:00 -0500, CrudeSausage wrote: >>>> >>>>> To remove the new Outlook app package after it's force installed on >>>>> your Windows device, you can use the Remove-AppxProvisionedPackage >>>>> cmdlet with the PackageName parameter value >>>>> Microsoft.OutlookForWindows. >>>>> >>>>> This can be done by running the following command from a Windows >>>>> PowerShell prompt and adding a new reg value: >>>>> >>>>> [Blah blah hoyvin-glayvin blah blah] >>>> >>>> This is why they say, Windows is a great OS -- if your time is worth >>>> nothing. >>>> >>> So which OS do you choose to expend your valuable time on? >> >> >> Linux is the only option worth pursuing. macOS is weird and expensive, >> Windows is bloatware beyond belief. >> >> > I agree. Plus it also counts as a religion, so you don't have to waste > time going to church anymore. https://www.whycatholic.com/even-in-the-beginning-their-were-heretics/ saint-linus/
[toc] | [prev] | [next] | [standalone]
| From | Chris <ithinkiam@gmail.com> |
|---|---|
| Date | 2025-01-15 11:33 +0000 |
| Message-ID | <vm86er$2u8jo$1@dont-email.me> |
| In reply to | #181311 |
Joel <joelcrump@gmail.com> wrote: > MikeS <MikeS@fred.com> wrote: >> On 12/01/2025 23:23, Lawrence D'Oliveiro wrote: >>> On Fri, 10 Jan 2025 12:37:00 -0500, CrudeSausage wrote: >>> >>>> To remove the new Outlook app package after it's force installed on your >>>> Windows device, you can use the Remove-AppxProvisionedPackage cmdlet >>>> with the PackageName parameter value Microsoft.OutlookForWindows. >>>> >>>> This can be done by running the following command from a Windows >>>> PowerShell prompt and adding a new reg value: >>>> >>>> [Blah blah hoyvin-glayvin blah blah] >>> >>> This is why they say, Windows is a great OS -- if your time is worth >>> nothing. >>> >> So which OS do you choose to expend your valuable time on? > > > Linux is the only option worth pursuing. macOS is weird and > expensive, Windows is bloatware beyond belief. macOS is free. Just needs a $600 mac to run it on.
[toc] | [prev] | [next] | [standalone]
| From | Joel <joelcrump@gmail.com> |
|---|---|
| Date | 2025-01-15 10:46 -0500 |
| Message-ID | <cqlfoj93e6jvua3is08kbm6f9p32h8cl4a@4ax.com> |
| In reply to | #181365 |
Chris <ithinkiam@gmail.com> wrote: >> Linux is the only option worth pursuing. macOS is weird and >> expensive, Windows is bloatware beyond belief. > >macOS is free. Just needs a $600 mac to run it on. Windows Home preinstalled on volume-produced gear is virtually free, self-installed Linux completely free, but yes that "$600" you cite isn't cheap for the device it buys. That OS upgrades are free is just to incentivize buying/using an Apple device. -- Joel W. Crump Amendment XIV Section 1. [...] No state shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any state deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws. Dobbs rewrites this, it is invalid precedent. States are liable for denying needed abortions, e.g. TX.
[toc] | [prev] | [next] | [standalone]
| From | -hh <recscuba_google@huntzinger.com> |
|---|---|
| Date | 2025-01-15 11:33 -0500 |
| Message-ID | <vm8o1d$313ov$1@dont-email.me> |
| In reply to | #181373 |
On 1/15/25 10:46 AM, Joel wrote: > Chris <ithinkiam@gmail.com> wrote: > >>> Linux is the only option worth pursuing. macOS is weird and >>> expensive, Windows is bloatware beyond belief. >> >> macOS is free. Just needs a $600 mac to run it on. > > Windows Home preinstalled on volume-produced gear is virtually free, > self-installed Linux completely free, but yes that "$600" you cite > isn't cheap for the device it buys. That OS upgrades are free is just > to incentivize buying/using an Apple device. > Where said "isn't cheap" $600 is ~half what Joel's already spent... ...or for when the Lady protests too much, after deducting off his alleged $200 mistake of a second Windows OS license, roughly 50% less ($600 vs ($1150 - $200 = $950). But don't let actual math get in one's way of a good narrative! /s -hh
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web