[mythtv-users] OT: A major difference between Widows and Linux

[Stephen P. Villano]

On 5/12/16 8:41 AM, Damian wrote:
> On 12/05/2016 11:02, Simon Hobson wrote:
>> Damian <myth at surr.co.uk> wrote:
>>
>>> A fundamental difference between Windows and Linux
>> Couldn't you have raised a less contentious topic like politics or
>> religion :D
>>
>>> it seems to me, is ...
>>> In Linux, if pretty much anything goes wrong, the user needs to
>>> enter some commands into the terminal in order to get to the bottom
>>> of the problem.
>>> In Windows, no matter what goes wrong, there is almost never a
>>> 'need' to go to the command line.
>> Go back a year or three and it's more like :
>> In Linux, everything is possible (even if a bit arcane and tricky to
>> configure), while in Windows the simple is easy and the difficult is
>> impossible (ie if there's no GUI button to click).
>> In Linux, when something goes wrong, it'll be isolated to something
>> that's visible and fixable, while in Windows it's often easiest to
>> just re-install the OS.
>>
>> On both, times they are a changin'
>>
>> With SystemD, Linux is rapidly moving over to the Windows ground of
>> big binary blobs of obfuscated functionality and many unrelated
>> functions rolled up into the one black box - with restricted
>> configurability and obfuscated logs that need a special program to
>> access. Windows on the other hand, is moving the other way, with
>> PowerShell and even Bash now !
>>
>> As someone else put it, debugging with SystemD is like fault finding
>> on electronics with nowhere to stick the voltmeter.
>>
>> It was often said long ago that "DOS is like Unix with the useful
>> stuff taken out" - with PowerShell and Bash, they're finally fixing
>> that. A few decades late, but ...
> Thanks everyone,
>
> I'll not respond to any individual point as I know the topic could
> snowball and be an annoying distraction from MythTV.
>
> Thanks for those of you who responded. Very interesting to read your
> thoughts.
>
> Cheers,
> Damian
I'm still trying to wrap my head around the thinking that one requires
the GUI to administer windows systems. I've rarely used the GUI to work
on and fix windows systems, I'd psexec a command prompt, examine and fix
what was broken, exit and call it a day. I had scripts set to psexec in
as well, they'd run in the background, fix a common thing that was
broken, exit and call it a day (wsus breaking comes to mind under XP Pro).
Linux doesn't have a GUI by default and design, the GUI is added by the
distro as a default GUI, which can be changed to an assortment of window
managers on top of the X windows system or other interface (kiosk
machines come to mind, I used one kiosk to check in for a lab test
yesterday, a whopping single button to push to start the process),
execute program, accomplish the goal of the task.
Windows originated in a DOS world, initially, networking didn't even
exist and networking was shoved under the hood, barely fitting
initially. Adding high memory helped, as the drivers initially left
little usable memory available, mouse, NIC driver, etc using the first
640k of available memory!
Yeah, I used to have Windows 1.0 discs around, lost them when my home
was emptied out during a long deployment...
Windows 95 tightened the GUI and DOS linkage, but didn't eliminate the
bolted on effect. I won't go into the ping of death or Microsoft lying
about its existence or worse, legal threats made by Microsoft against
those reporting the bug... Their decision to switch to Sun Solaris
servers, when their NT4 boxes couldn't stay operating, due to "network
load issues" (they were being crashed by tens of thousands of scripted
ping of death attacks). Windows 2000 finally started cementing the GUI
on, with a finer layer of shellac on top of the varnish, covering the
cracks.

So, where are we today?
We've had compromises of Windows hosts on our network, the compromises
were all command line attacks, although a couple of successful
compromises started at the CLI and ended in an RDP session for the
convenience of the attacker. Have the command line, own the host.
Which is precisely where we started.