A circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex
-
@blakeyrat said:
And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012? I can guarantee I don't if I'm using Microsoft's RDP.
I can guarantee I don't if I'm using ssh into any Debian or Ubuntu box from any other Debian or Ubuntu or RedHat box too; they and all the terminal emulators packaged for them all use UTF-8 by default.
PuTTY doesn't; for some reason I fail to understand, it defaults to ISO-8859-1. But it's easy enough to set up a PuTTY profile you can use to connect to your Ubuntu server that has the correct encoding selected. If you want, you can also add the -load command line option to the shortcut you use to launch PuTTY, so it comes straight up with the appropriate profile in use.
In any case, blaming "Linux" for a poor choice of default on the part of your preferred Windows-based ssh client seems a little harsh to me.
-
@Daniel Beardsmore said:
@jes said:
technically accurate but point-missing babbling …
Which is all well and good, but in no way does anything you wrote excuse the design. That's the whole point.
It sounds like SSH is really more akin to a VPN. You wouldn't blame your VPN if your FTP server couldn't handle special characters.
So the responsibility belongs to... whom? Bash?
-
@joe.edwards said:
It sounds like SSH is really more akin to a VPN. You wouldn't blame your VPN if your FTP server couldn't handle special characters.
So the responsibility belongs to... whom? Bash?
I'm not about buck-passing, I'm about bug-fixing.
If the spec says UTF-8 is the default, then obviously PuTTY is in the wrong. If not, then it's not. It might even be the case that, like so many things in the web world, PuTTY is actually doing it according to the specs but isn't inter-operable because nothing else does.
But the real, real problem identified in this thread is the people who, presented with an obvious bug, reply with, "I don't want that to be fixed!"
-
@joe.edwards said:
It sounds like SSH is really more akin to a VPN. You wouldn't blame your VPN if your FTP server couldn't handle special characters.
It's a lot like RDPing into a server with different locale settings than you have set up, considering that the encoding is part of your locale setup.
-
@boomzilla said:
@joe.edwards said:
Once again it is demonstrated that the real problem is those damn foreigners.It sounds like SSH is really more akin to a VPN. You wouldn't blame your VPN if your FTP server couldn't handle special characters.
It's a lot like RDPing into a server with different locale settings than you have set up, considering that the encoding is part of your locale setup.
-
@joe.edwards said:
It sounds like SSH is really more akin to a VPN. You wouldn't blame your VPN if your FTP server couldn't handle special characters.
So the responsibility belongs to... whom? Bash?
Even if SSH when used as a shell¹ is literally just a tunnel for raw characters sent from bash to your PC and back, that does not preclude session initialisation, i.e. "I'm a UTF-8 machine, now off we go." Any remotely sane person would have some level of communication prior to the raw character stream for future proofing alone. If you're going to design a remote shell protocol properly then this is a really good time to centralise all the interoperability concerns and automate them.
¹I think some of you are having trouble differentiating the shell concept from the secure concept. The problem here isn't the encryption or tunnelling, the problem is the actual remote shell facility.
-
"Typical" Windows mentality: Nobody will pay for the next version of our software unless we do more for them and make their lives easier.
"Typical" Linux mentality: The tool works, so it is up to the user to figure out how to make it do what they want. If it doesn't do what they want, they can change it. They didn't pay for it, so anything I can give them is more than they had.
As a user, I prefer the Windows mentality. As a developer, I prefer the Linux mentality. Generally speaking, nobody likes auditing for standards compliance, but it makes for a higher quality product. This doesn't matter when your user base is already composed of die-hard fans, but you exclude casual users--Windows has a commanding share of the desktop marketplace because of it.
If you have a unified package manager for all applications in your operating system, all applications should provide a uniform eperience. When I use an Adobe updater, I implicitly accept that it will look and function differently than Steam's updater. When different components in the Microsoft updater function differently, it irks me, but that hasn't happened to me in... at least 10 years? Its been a while.
-
@blakeyrat said:
If the spec says UTF-8 is the default, then obviously PuTTY is in the wrong. If not, then it's not. It might even be the case that, like so many things in the web world, PuTTY is actually doing it according to the specs but isn't inter-operable because nothing else does.
There isn't a spec, as far as I know; ssh just shovels 8-bit bytes from one end of the connection to the other, and apart from a few well-specified and generally unobtrusive in-band control characters on the main command shell channel, it's totally up to the server and the client to pre-agree on what characters those bytes represent. Nothing in the ssh spec would stop you using EBCDIC over ssh, if you were of a mind to.
Character encoding is one of the things you typically set up when first installing a *nix server, and in this day and age most people pick UTF-8 because that's what most of the distros offer as a default because for most use cases it works better than any other option.
UTF-8 was invented in 1992, but didn't really get popular until the early 2000s (Windows 95, notably, ignored it in favour of UCS-2/UTF-16LE). PuTTY first appeared in 1999, and I imagine its defaults have remained unchanged since then for backward compatibility reasons.
-
@blakeyrat said:
@Mcoder said:
What I don't want is a ssh protocol that is aware of character encoding.
... why?
Please look at layers 5, 6 and 7 shown here: http://en.wikipedia.org/wiki/OSI_model?
SSHD is layer 5, Session, and should be machine and character agnostic, because that is what most programs that use sshd expect.
-
@blakeyrat said:
No, the real, real problem is that someone who admits to being unqualified to even administer Linux nonetheless feels qualified to discuss its design.But the real, real problem identified in this thread is the people who, presented with an obvious bug, reply with, "I don't want that to be fixed!"
-
@El_Heffe said:
Once again it is demonstrated that the real problem is those damn foreigners.
Exactly. What we need is one standard worldwide language. And it obviously ought to be English, because that's what I speak.
Kind of fun to note that Esperanto is a perfect example of the XKCD "15th standard" effect and dates from well before computing standards were a thing.
-
@PedanticCurmudgeon said:
No, the real, real problem is that someone who admits to being unqualified to even administer Linux nonetheless feels qualified to discuss its design.
People who know the system top-to-bottom aren't well-qualified to critique it. They don't notice the problems.
In any case, look at the screenshot posted here... do you not agree that is a bug?
-
This whole "not my problem" attitude in this thread is probably a good indication of why so many protocols and standards suck.
Who said that the person using the SSH client even owns the server to which they are connecting? How does the user even know what character encoding has been set at the other end?
-
@blakeyrat said:
People who know the system top-to-bottom aren't well-qualified to critique it. They don't notice the problems.
They also don't cause problems as a result of not knowing what they're doing, but that's not the point. Linux is not Windows. The design is totally different and things fit together in ways you're totally unaccustomed to. That doesn't mean it's broken. It does mean that if you're going to continue to administer Linux boxes you have two choices:
- Shut up and learn something
- Continue complaining and end up as even more of a bitter shell of a man than you are now
Everything I've seen on this thread so far indicates it's either a problem with your ssh client, or it's a configuration fail on your part.In any case, look at the screenshot posted here... do you not agree that is a bug?
-
@blakeyrat said:
In any case, look at the screenshot posted here... do you not agree that is a bug?
I think we all agree that there is a bug somewhere. There's an argument to be made that part of the protocol should require negotiation of the encoding (this seems fairly reasonable, but for backwards compatibility, etc, is probably a non-starter). There are other arguments to the effect that the bug is in either the server or the client or both. And some people think it's more fun to simply wail about the existence of the bug and at those who might be interested in discussing where the bug lies.
-
@PedanticCurmudgeon said:
Everything I've seen on this thread so far indicates it's either a problem with your ssh client, or it's a configuration fail on your part.
I didn't modify any configuration, it's a bug.
-
@Kaosadvokit said:
"Typical" Windows mentality: Nobody will pay for the next version of our software unless we do more for them and make their lives easier.
"Typical" Linux mentality: The tool works, so it is up to the user to figure out how to make it do what they want. If it doesn't do what they want, they can change it. They didn't pay for it, so anything I can give them is more than they had.
That strikes me as fair comment.
One of the pitfalls that the Windows mentality leads to, it seems to me, is an inexorable drive toward tools with complex behaviours designed to second-guess the user's intent. When this works, as it apparently does for some people, it's great. But for people like me, whose interactions with Windows boxes consist mostly of setting them up and maintaining them and fixing them when they break, most of the second-guessing stuff just leaves me wondering what the hell the box is up to this time and wishing I could see inside it better.
Which is exactly why I prefer Linux tools for my own use: only a notorious few (e.g. sendmail, emacs) attempt to do everything; by and large the individual tools have reasonably simple and sane and comprehensible behaviors, and such challenges as their usage involves are generally the creative kind (how can I glue these tools together to make something that suits the task at hand?) rather than the head-desk kind (how can I turn off all this extra crap I don't want to happen, and why do these tools break down so egregiously at the first whiff of an edge case?). And not even editing sendmail config files gets old as fast as Clippy.
I'm kind of an inverse Blakeyrat in this respect. I enjoy command line interfaces; most of what I do is maintenance of one kind or another, and I very much like being able to grab the last few things I found myself needing to do, shove them as-is into a script file, then maybe tweak that a bit for generality. I like the way Unix command-line tools are generally built so as to make using the outputs of one as inputs to another mostly painless. I like the fact that the objects the tools pass amongst themselves are the exact same text I'd type into them and read from them, rather than some kind of complex binary blob requiring a serializer to look inside of, and I so prefer Bourne shell to PowerShell.
But I can see the point of the Windows mentality. It clearly suits a lot of people very well, and that's just fine by me. I can also quite easily understand how somebody like Blakeyrat, who is accustomed to working within that ecosystem, would suffer just as much when forced to use my preferred toolkit as I would suffer and have suffered when forced to use his. But I do wish he'd dial back the "your tools all SUCK!" rhetoric, because in truth they don't suck much at all; what sucks is an employer that refuses to hire a competent Linux geek to maintain the company Linux boxes and/or migrate to an environment with which the existing personnel feel comfortable and at home.
-
@blakeyrat said:
I didn't modify any configuration, it's a bug.
Yes, but it's not a bug in any of the tools you're using; it's an interoperability bug, which you will indeed need to modify one configuration item to fix unless you move to different tools with compatible default configurations. But since PuTTY is by far the best Windows ssh client available, I suggest that simply creating a connection profile with the character encoding set correctly is your path of least work here.
-
@blakeyrat said:
People who know the system top-to-bottom aren't well-qualified to critique it. They don't notice the problems.
Leaving aside the idea that almost-complete ignorance is an adequate foundation for criticism, your complaints aren't even original. They're pretty much all in the Unix-Haters Handbook, which apparently you still haven't read.
-
First of all, before I comment on it, thanks for a very fair and intelligent post that considers more than your own viewpoint.
@flabdablet said:
One of the pitfalls that the Windows mentality leads to, it seems to me, is an inexorable drive toward tools with complex behaviours designed to second-guess the user's intent.
I see it as being "dumb" versus "not dumb". A script that tells me it has to restart services when the entire computer needs to be restarted less than a minute down the road? To me that's dumb, and it bugs me-- computers should be smart, not dumb. A computer asking me a question it should be able to easily answer on its own? Bugs the shit out of me.
@flabdablet said:
I like the fact that the objects the tools pass amongst themselves are the exact same text I'd type into them and read from them, rather than some kind of complex binary blob requiring a serializer to look inside of, and I so prefer Bourne shell to PowerShell.
That works if, and only if, the data you're interested in is text, or can be sanely represented as text. Most data people (not you people, normal average people) use isn't. That's the problem PowerShell is intended to solve. (Well, one of them.)
@flabdablet said:
But I do wish he'd dial back the "your tools all SUCK!" rhetoric, because in truth they don't suck much at all; what sucks is an employer that refuses to hire a competent Linux geek to maintain the company Linux boxes and/or migrate to an environment with which the existing personnel feel comfortable and at home.
I agree with that, amen.
... but the tools do suck in many significant ways. And one of the most significant is that they're all stagnant-- the entire ecosystem, no decision gets re-examined, nothing gets re-designed, nothing gets fixed if it affects anything else, and there's no separation of machine-readable data and human-readable data. You'll never get a Office 2007 ribbon in the Linux ecosystem, that level of innovation just doesn't exist.
-
@PedanticCurmudgeon said:
They're pretty much all in the Unix-Haters Handbook, which apparently you still haven't read.
So why haven't they been fixed? If they're long-known standing bugs?
-
@blakeyrat said:
@PedanticCurmudgeon said:
And that's the fail. If it is a bug, the fault is with the client. Given that the majority of connections will be to *nix boxes, most of which are configured to use UTF-8, your client should have had that as the default. But I'm sure you'll find some way to blame that on Linux.Everything I've seen on this thread so far indicates it's either a problem with your ssh client, or it's a configuration fail on your part.
I didn't modify any configuration
-
@Daniel Beardsmore said:
Who said that the person using the SSH client even owns the server to which they are connecting? How does the user even know what character encoding has been set at the other end?
Ask the server. On a box with GNU tools, the locale command will report that stuff, and since its output is pure ASCII it will be readable regardless of your terminal's initial character encoding setting. Unless you've picked EBCDIC just to make a point.
-
@blakeyrat said:
@PedanticCurmudgeon said:
They're not bugs, they're design choices that you don't agree with.They're pretty much all in the Unix-Haters Handbook, which apparently you still haven't read.
So why haven't they been fixed? If they're long-known standing bugs?
-
@PedanticCurmudgeon said:
They're not bugs, they're design choices that you don't agree with.
I only complain about things that are broken or stupid. So you're saying the design choice is to be broken and stupid.
-
@blakeyrat said:
I only complain about things that are broken or stupid according to my admittedly limited knowledge of how things work.
FTFY
-
@flabdablet said:
Ask the server. On a box with GNU tools, the locale command will report that stuff …
*I* know that (I posted output from locale earlier) but the person who designed SSH didn't appear to know that.
There is a difference, albeit fine at times, between a system guessing things for you that you needed to specify, and belligerently refusing to show any intelligence and putting all the workload on the user needlessly.
SSH and character encoding is definitely the latter. A letter "a" is a letter "a" – very few people have any need to care how a letter "a" makes its way down the wire. It's important to know what text the server is transmitting, but not how.
Anyway, I give up.
-
I'm still waiting to see how my own level of experience is relevant.
-
@PedanticCurmudgeon said:
@blakeyrat said:
No, they are design choices that a lot of people think are wrong and stupid. If something has enough things wrong with it, and so many people who think those things are wrong that you can write a whole book about it, you've got a legitimate problem that can't just be dismissed as "you just don't know what you're doing". Blakey put it perfectly, the entire eco-system is stagnant and nothing that is badly designed ever gets changed (or maybe you are so delusional that you think that it's perfect and none of it is badly designed).@PedanticCurmudgeon said:
They're not bugs, they're design choices that you don't agree with.They're pretty much all in the Unix-Haters Handbook, which apparently you still haven't read.
So why haven't they been fixed? If they're long-known standing bugs?
Saddly, he blew his entire argument by citing the Office 2007 ribbon as "innovation".
-
@blakeyrat said:
I see it as being "dumb" versus "not dumb". A script that tells me it has to restart services when the entire computer needs to be restarted less than a minute down the road? To me that's dumb, and it bugs me-- computers should be smart, not dumb. A computer asking me a question it should be able to easily answer on its own? Bugs the shit out of me.
You see dumb, I see appropriate code re-use. That script that's telling you it has to restart services is a component, and it's been designed not to care much when it gets called. It's got a simple job to do, it needs to restart a service to complete that job, and then it's outta there; it's cleanly separable from the context you first encountered it in, and can be re-used in other contexts without causing too many surprises.
I can see why it bugs you, because you just want to get your job done and you really don't care much how. Personally I like feeling like I have some clue about what's going on under the hood, and what bugs me is coding that makes a computer with less CPU power than your average cockroach brain behave in ways that simulate smartness - poorly. From my point of view computers are not smart, will probably not become smart in my lifetime, and attempts to make them seem smart smack of cargo cultism; I'll happily put up with quite a lot of exposed dumb, if the tradeoff is high predictability.
@blakeyrat said:
That works if, and only if, the data you're interested in is text, or can be sanely represented as text. Most data people (not you people, normal average people) use isn't. That's the problem PowerShell is intended to solve. (Well, one of them.)
Sure, serializing and unserializing data can often represent avoidable overhead. But if you find yourself needing to do more than a very small amount of that in a bash script, that's a strong clue that bash is not the best tool for the job at hand. I do agree that the bash hammer does get used to pound more nails than perhaps it should, and I'll also happily agree that peering at text streams with a pager is hella crude as debugging techniques go; but it's quite amazing how often it's all the debugging technique that's called for.
From where I sit, PowerShell looks like XKCD's 15th standard again; it's a vast and complicated solution to a non-problem. Windows already had perfectly adequate scripting (Visual Studio debugger and JScript) and all that really needed to happen was that the COM to JScript interfaces got cleaned up a bit, perhaps with a smallish library of helper functions in WSH; instead we get this ugly fucking thing with an "object pipeline". Who TF needs to put objects in a pipeline? And if you really do, why not just use a pipeline object inside an existing general purpose OO language instead of baking the thing into a privileged position with a bunch of complicated special-case semantics? It's as if somebody looked at Bourne shell and thought "you know what? That thing isn't complicated enough." Well, they should have read the Bugs section of the Bash man page (which says "it's too big and it's too slow") first.
I don't believe that being The Language on a computer system is a fit and proper ambition for a shell interpreter. PowerShell, to me, is one more confirmation that spakfilla and glue are indeed seen as legitimate structural materials by the designers at Redmond. I truly dislike using it, and will reach for JScript instead in 99 cases out of 100.
@blakeyrat said:
... but the tools do suck in many significant ways.
You see suck, I see legitimate engineering tradeoffs.
@blakeyrat said:
And one of the most significant is that they're all stagnant-- the entire ecosystem, no decision gets re-examined, nothing gets re-designed, nothing gets fixed if it affects anything else
Well maybe, but to the extent that this is true of Linux and related systems it's also a general misfeature of every cultural artifact that any culture ever has ever come up with ever. It's not unique to Linux. Not even close.
@blakeyrat said:
and there's no separation of machine-readable data and human-readable data.
From where I sit, to the extent that this is true it's a feature. I like being able to look at stuff. And I like having available a large range of tools to help me look at stuff. I like that I can fire up sqlite and look inside some other project's .sqlite files. I like that most of such binary-blob file formats as are in widespread use are well documented. And I especially like that there's a conventional norm for using text formats for config information, and for including comments inside that config information. I've often wished that the Windows registry had a comments feature and that it was used.
@blakeyrat said:
You'll never get a Office 2007 ribbon in the Linux ecosystem, that level of innovation just doesn't exist.
Oh come now. The Ribbon is by no means the only example of hideous innovation in UI misdesign; there are trend-setting UI misdesigners all over the place stamping their hobnailed boots into the faces of our collective muscle memory for no better reason than the collection of accolades from other trendy UI misdesigners. Look at Canonical's hideous Unity graphical shell, or the Gnome project's hideous Gnome Shell, or Redmond's awful Metro. These turds are blossoming everywhere.
-
@flabdablet said:
Well maybe, but to the extent that this is true of Linux and related systems it's also a general misfeature of every cultural artifact that any culture ever has ever come up with ever. It's not unique to Linux. Not even close.
That doesn't mean I like it, or even that it's acceptable.
@flabdablet said:
From where I sit, to the extent that this is true it's a feature. I like being able to look at stuff. And I like having available a large range of tools to help me look at stuff. I like that I can fire up sqlite and look inside some other project's .sqlite files. I like that most of such binary-blob file formats as are in widespread use are well documented. And I especially like that there's a conventional norm for using text formats for config information, and for including comments inside that config information.
But if your machines are taking using the same channel as the humans, that means you either need humans to learn to read like machines (unlikely to ever become popular) or you need the machines to expose data in human-readable fashion. And regardless of which you choose, you've cemented it forever and ever and ever, you can't even fix a typo because somewhere there's some script reading your psuedo-human-readable text and breaking due to the typo.
Even Mac Classic in 1984 got that one correct with its "Gestalt" API call.
@flabdablet said:
I've often wished that the Windows registry had a comments feature and that it was used.
Valid. I would also like to point out that if you're looking in the Registry, for any reason other than "I work at Microsoft and it's my job to build the Registry" you are undoubtedly doing something wrong.
People looking into the Registry and assuming that retrieving data from there instead of using the proper APIs is a HUGE source of WTFs in the Windows world.
@flabdablet said:
Oh come now. The Ribbon is by no means the only example of hideous innovation in UI misdesign; there are trend-setting UI misdesigners all over the place stamping their hobnailed boots into the faces of our collective muscle memory for no better reason than the collection of accolades from other trendy UI misdesigners. Look at Canonical's hideous Unity graphical shell, or the Gnome project's hideous Gnome Shell, or Redmond's awful Metro. These turds are blossoming everywhere.
Jesus, could you guys just stamp "crotchety Luddite" to your sig so I know to ignore your idiotic grandma ramblings? 3 posts ago I actually respected you, what a mistake.
Ok, we get it: you hate change. CHANGE! OMG! It's like Stalin and Hitler mixed into one horrible concept! We get it. If you hate change, you should not participate in these discussions because you are not relevant to them.
-
@El_Heffe said:
No, they are design choices that a lot of people think are wrong and stupid. If something has enough things wrong with it, and so many people who think those things are wrong that you can write a whole book about it, you've got a legitimate problem that can't just be dismissed as "you just don't know what you're doing".
Yes, and the legitimate problem is that people insist on using *nix who should be using something else. The Unix-Haters Handbook was largely written by people who'd rather have been using VMS or Lisp Machines. *nix is a perfectly valid design model, and works well for the set of people it was designed for, but it's not for everyone.
-
@blakeyrat said:
I'm still waiting to see how my own level of experience is relevant.
experience != knowledge
-
@PedanticCurmudgeon said:
@blakeyrat said:
I'm still waiting to see how my own level of experience is relevant.
experience != knowledgeI'm still waiting to see how my own level of knowledge is relevant.
-
-
@Daniel Beardsmore said:
I know that (I posted output from locale earlier) but the person who designed SSH didn't appear to know that.
...or perhaps, as seems to me to be the case, the person who designed ssh saw it as a tool that could be implemented on loads of different systems, some of which don't even have a concept of locale at all, and chose to have the tool solve only those problems that it needed to do in order to accomplish its primary function, viz. establishing secure tunnelled connections between terminals on possibly disparate boxes over an insecure interconnecting network.
Also relevant is the fact that locale is a concept that doesn't even belong in the ssh layer. It's a terminal emulator thing, not a communication channel thing. The communication channel shouldn't need to care what it's communicating; as long as whatever you put in one end comes out the other, it's doing its job.
PuTTY is a combination ssh client, telnet client, modem client and terminal emulator, and it was the judgement call of its designer that ISO-8859-1 was the appropriate default character encoding for the terminal emulator part, and that the terminal emulator should remain agnostic about what it's going to be used as a terminal to. I think those are perfectly defensible choices, even though I also think UTF-8 would be a better default character encoding in 2012.
-
@blakeyrat said:
3 posts ago I actually respected you, what a mistake.
The clown shoes avatar was the clue you missed there, I suspect.
@blakeyrat said:
Ok, we get it: you hate change. CHANGE! OMG! It's like Stalin and Hitler mixed into one horrible concept! We get it. If you hate change, you should not participate in these discussions because you are not relevant to them.
Some change is good. Change that removes small irritants: good. Change that is instantly self-explanatory and clearly easier to use than what came before: good (the desktop UI transition from Windows 3 to Windows 95 is an excellent example). Change that causes an entire world full of office workers to need retraining for no clear benefit: not good, especially when that lipstick has been slapped on a pig as ugly as Outlook.
I don't mind having my cheese moved. I do mind having the cheese mountain I have carefully sculpted over several years to suit my own work patterns forcibly removed, replaced with something slower to use, less flexible and "prettier", and then being told that the only reason I don't like what's just happened is that I "fear change".
So sure, make change available. But unless your change really is as good as Windows 95 compared to its contemporary Mac OS and/or Windows 3, I'd be much much happier if you didn't make it mandatory.
-
@blakeyrat said:
... regardless of which you choose, you've cemented it forever and ever and ever, you can't even fix a typo because somewhere there's some script reading your psuedo-human-readable text and breaking due to the typo.
We get it. You hate change. CHANGE! OMG! It's like Stalin and Hitler mixed into one horrible concept! We get it.
But seriously: stuff breaks all the time. That's part of what distro maintainers exist to stay on top of, and most of them are good enough at what they do that stuff doesn't stay broken for very long.
There's all kinds of soapy matted hair littering the Windows APIs as well, only retained for backward compatibility with some busted old app somewhere. I agree that it's annoying but I don't see that it's unique to text-based interfaces and/or Linux.
-
@flabdablet said:
Change that causes an entire world full of office workers to need retraining for no clear benefit: not good, especially when that lipstick has been slapped on a pig as ugly as Outlook.
The benefit isn't clear to you, but it's clear to Microsoft and anybody else who reads Jensen Harris' blog. Or do you honestly think Microsoft would have risked their hugest income driver for a change that had no clear benefit?
@flabdablet said:
I don't mind having my cheese moved. I do mind having the cheese mountain I have carefully sculpted over several years to suit my own work patterns forcibly removed
Who forced you? Blame them.
@flabdablet said:
So sure, make change available. But unless your change really is as good as Windows 95 compared to its contemporary Mac OS and/or Windows 3, I'd be much much happier if you didn't make it mandatory.
Every checkbox in a product doubles the QA time. Providing more than one UI increases bugginess. It's a bad idea.
-
@flabdablet said:
There's all kinds of soapy matted hair littering the Windows APIs as well, only retained for backward compatibility with some busted old app somewhere. I agree that it's annoying but I don't see that it's unique to text-based interfaces and/or Linux.
In Linux, the users see it.
-
@PedanticCurmudgeon said:
And that's the fail. If it is a bug, the fault is with the client. Given that the majority of connections will be to *nix boxes, most of which are configured to use UTF-8, your client should have had that as the default. But I'm sure you'll find some way to blame that on Linux.
Here's what it boils down to:The server is using 8N1. The client is using 7E1. Fix the client to use 8N1. If the client isn't capable of 8N1, use a client that is. Problem solved. Nothing wrong with the output of the server itself. This is not a Linux problem.
-
@blakeyrat said:
Who forced you? Blame them.
Oh, I did. At length. In detail. With examples. And I was told that I should shut up, along with everybody else who "fears change".
I'm not using Gnome any more, because I find the UI currently offered by the Gnome developers completely irritating; the everything-is-a-phone brain worms seem to be completely in charge over there. There's a Gnome 2 fork called MATE, but my attachment to Gnome in particular was not as strong as my attachment to an easily accessible desktop with decent panels and good window controls, and by the time MATE became conveniently available as a Debian package I had overcome my fear of change enough to switch completely to Xfce and have not yet been given any reason to switch again.
So, imagine for a second that I'm a Windows user, and having taken inspiration from my Linux-desktop using friends I've got my Start menu all nicely organized by functional category instead of the manufacturer or product name folders that the installers create by default, and I like my Start menu and am comfortable with it and I no longer need to waste time looking through it for that app I haven't used for six months because I know where it will be when I need it - and I turn up to work to find that IT has slapped Windows 8 on my workstation and I'm expected to navigate this instead.
It's not OK because if they take my stapler then I'll set the building on fire.
-
@blakeyrat said:
In Linux, the users see it.
Only if they go looking for it. I've got Ubuntu and Debian installations on customer machines all over my home town, and the people who have them don't notice much difference from Windows except that their computer runs faster and quieter because it's not spending half its CPU power trembling in fear of viruses and they're not being bombarded by incomprehensible popups from fifteen different software updaters. Cruft in APIs as as remote from their consciousness as you'd expect from any non-technical user.
Those installations, by the way, require less than a quarter of the time spent on technical support each as is typical for my Windows-using customers. Using Debian instead of Windows also means I can take a box from bare metal to fully-updated customer-useful computer in about half the time. And that's not because I suck at doing Windows installs; I don't.
-
What gets me is the fact that it's âââââââââ instead of ─── - this implies the curses library or equivalent is [i]emitting a cursor positioning sequence for every single character[/i].
-
@blakeyrat said:
Or do you honestly think Microsoft would have risked their hugest income driver for a change that had no clear benefit?
I think Ballmer lacks technical judgement and taste, and I think there are designers at Microsoft who know exactly how many lines he needs to have snorted before whispering the magic word "innovation" in his ear will get the desired result.
-
@flabdablet said:
@blakeyrat said:
In Linux, the users see it.
Only if they go looking for it. I've got Ubuntu and Debian installations on customer machines all over my home town, and the people who have them don't notice much difference from Windows except that their computer runs faster and quieter because it's not spending half its CPU power trembling in fear of viruses and they're not being bombarded by incomprehensible popups from fifteen different software updaters. Cruft in APIs as as remote from their consciousness as you'd expect from any non-technical user.
Those installations, by the way, require less than a quarter of the time spent on technical support each as is typical for my Windows-using customers. Using Debian instead of Windows also means I can take a box from bare metal to fully-updated customer-useful computer in about half the time. And that's not because I suck at doing Windows installs; I don't.
So has anyone ever called you asking why they can't install Office or something?
-
@MiffTheFox said:
So has anyone ever called you asking why they can't install Office or something?
No, because before installing Ubuntu or Debian I've always explained very clearly that Linux-based systems cannot, in general, run the same application software as Windows-based systems, and that this has both a downside (there will be some familiar software you can't install, for which you will need to get used to using some free alternative) and an upside (none of the Windows malware is compatible either). I've also explained what "application software" means, to several people who were previously unclear on the distinction between Microsoft Windows and Microsoft Office.
I do have a couple of customers whose existing Windows licences I've used to set up a dedicated Windows VM inside their Debian user accounts, solely for running things like Quickbooks that they need to use for their businesses. One of those ended up installing iTunes in there as well to give her access to the Apple music store. It's nice being able to revert a Windows VM to a known-clean snapshot at the first suspicion of infection.
Of the sixteen Linux installations I'm directly responsible for, only one has asked me to put Windows back on instead. Which I naturally did for free.
-
@blakeyrat said:
@flabdablet said:
There's all kinds of soapy matted hair littering the Windows APIs as well, only retained for backward compatibility with some busted old app somewhere. I agree that it's annoying but I don't see that it's unique to text-based interfaces and/or Linux.
In Linux, the users see it.
The users see the sticky-out parts of weird old design decisions in all computing systems. Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing < > : " / \ | ? or *, solely because the CP/M command interpreter and the DOS command interpreters based on it had no reasonable parser and no reasonable filename quoting mechanism.
Yes, these quirks are kind of annoying. But no more so than the quirks in, say, English. Personally I think they're kind of charming; at the very least they provide some kind of incentive to dig into computing history, which is something I think you and I both agree should be done more often by more people.
-
@flabdablet said:
The users see the sticky-out parts of weird old design decisions in all computing systems. Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing : " / \ | ? or *, solely because the CP/M command interpreter and the DOS command interpreters based on it had no reasonable parser and no reasonable filename quoting mechanism.
I'd love to see volume letters go the way of the dinosaur. I know this will never happen, but I really love being able to mount arbitrary devices and shares anywhere in the filesystem in Linux.
I actually use Windows as my primary operating system, mainly because my work is all .NET and T-SQL, and at home I want to play new games... but I basically love the Linux philosophy, open source, the Bourne Again shell, text file configuration, Aptitude, the GNU toolchain - all the stuff Blakey hates so passionately.
-
@flabdablet said:
Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing : " / \ | ? or *
Still better than having a file whose name is the bell character. Or the newline character (Watch in awe as every shell script breaks on that one!).
Unix does have a choice when it comes to fixing bugs, you know.
They could develop a new API, and keep the old one around for legacy reasons. Then new programs could access the non-buggy, new API. Without affecting backwards compatibility.
But that wont happen, will it? It would require admitting that shit is broken or badly designed.
