|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, maybe they shouldn't actively dissuade people from filing bugs by
>> making it so sodding hard to file a bug? :-P
>
> It *isn't* hard. I've filed many bugs over the years, and it isn't the
> oh-so-difficult process you seem to think it is -
The account setup process seemed tortuously difficult to me. I spent a
full two weeks trying to work around the problem before I finally gave
up and tried to file a ticket.
> based on exactly ZERO experience doing so.
Zero experience?
Perhaps you're missing the part where I actually *did* all this to file
a bug (which, last I checked, is still open). Basically Zypper gives you
an incorrect error message - but apparently Zypper just tells you what
Curl tells it. So until Curl gets fixed...
>> You know what's *really* annoying? Seeing an open bug for THE EXACT
>> PROBLEM that our production application has, seeing that upstream has
>> fixed it, and yet OpenSUSE refuses to release an RPM for it. *That* is
>> annoying! (We're talking about a different bug now. The ticket has been
>> open for many months. The fix is literally to build a new RPM. Yet it
>> isn't happening...)
>
> Example? Because for that bug, I'd like to nudge someone, or at least
> find out why.
In OpenSUSE 13.1, systemd hangs for 60 seconds on shutdown. It's waiting
for... I forget what it is now, but after 60 seconds it gives up and
shuts down anyway. It just means every time you want to shut your PC
down, you have to needlessly wait 60 seconds before it does it.
The bug is fixed in systemd 209 (?), but the latest official RPM from
OpenSUSE is 208, which doesn't contain the fix. (There was some talk
about the upstream "fix" being a bit of a kludge... I'm not sure exactly
how true that is. I just want the bug to go away.)
Somebody filed a ticket. Somebody else said "here, try this RPM and let
me know if that fixes it". The original poster never let anybody know if
it worked. Ticket is currently set to "waiting for information" or similar.
>>> Not sure what you mean by "show task list option". What was the
>>> specific thing you were trying to do?
>>
>> The option to have an icon for each window that's open, so you can
>> instantly switch between windows (or just tell when a hidden window
>> closes itself). You know, like the Windows taskbar.
>
> Oh, like the dash-to-dock extension gives you. Yeah, that extension is
> one that I use, and it works great.
I, too, eventually found an extension that could be configured to behave
in a suitable manner. It just annoyed me that this is some unsupported
3rd-party hack, rather than part of the basic functionality of the shell.
>> Well, I don't know man. Version 2 of a product has a heap of features
>> which are gone in version 3. To be, that means that version 3
>> *objectively* has fewer features. I didn't think there's much to argue
>> about that...
>
> I used GNOME2, and I use GNOME3. Both did the job I needed, so I don't
> really care if there are "fewer features", because features I don't use
> are unimportant to me. Hence, personal preference.
I would have thought "seeing what windows are open and moving windows
around" is a pretty core functionality to a window manager. But
apparently your mileage is different...
> So no, you didn't ask for help, yet you complain about not being able to
> get help. That's telling.
>
>> In seriousness: I asked on Stack Overflow. The question was upvoted
>> several times, and many other people lamented the utter lack of any
>> documentation. But nobody actually answered the question. Which is what
>> happens when nobody knows the answer!
>
> One venue, where GNOME development isn't a primary discussion topic, does
> not mean "nobody knows the answer". Except in your world, it would seem.
Stack Overflow is only the single largest place to get help about any
programming problem you might have. If not one single person who
happened upon a GNOME question explicitly flagged with the GNOME tag
knows how to do a thing, it can't be that well-known. (And if it *was*
well-known, surely there wouldn't be so many people up-voting the
question. Rather, they'd be saying "dude, read the manual, it's right
here!")
>>> And "deleting code from the running system" isn't the same as extending
>>> it.
>>
>> From what I've seen, you write extensions by deleting existing objects
>> and replacing them with new ones. (Or maybe just replacing a method or
>> two.) You'd think it works by creating a new object that exposes a
>> defined set of operations, and passing that to the framework. But no, it
>> seems you just put your hands in the framework, rip out the bits you
>> don't want, and then replace them.
>
> Overriding is not the same as "ripping out the bits you don't want and
> replacing them". You should know that from your study of OOP methods.
Thing is, when you override a method, you're not destroying the old
implementation. You're creating a new class that works differently.
Anybody using the old class still gets the old behaviour. This is
different; you're dynamically deleting the code from the system while
it's still running - potentially even while somebody is trying to *call*
that code!
I mean, it *works* and all... It just seems like a pretty scary design.
>> And then watch it all break horrifyingly in the next minor-release of
>> the shell.>_<
>
> If you refuse to find the right venue to ask for help, then you kinda get
> what you deserve there.
I'm talking about all the extensions that *other* people wrote which
break on later versions of the shell. (My own extension actually
survived - mostly because it barely does anything.)
>> Still, IMHO, I think most of this brokenness goes back to "we decided to
>> build a huge, complex application in a scripting language". All problems
>> flow from there.
>
> Now there's something I might be able to get behind.
Somehow I doubt the GNOME foundation are going to change it tho. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> GNOME 2 had it, and there's a dozen different mutually-incompatible
> extensions to add it back to GNOME 3. Because it's a basic feature that
> should have been in the shell to begin with. But hey, it's a tablet. Who
> runs multiple applications on a tablet?
You are aware that on one of the most popular tablet (and phone) OS's
there's a dedicated button on every screen (one of only 3, the other two
are home and back) that allows you switch between applications? I'm
pretty sure they didn't decide to put it there just because it looked nice.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.03.2015 um 21:45 schrieb Orchid Win7 v1:
>>> Well, maybe they shouldn't actively dissuade people from filing bugs by
>>> making it so sodding hard to file a bug? :-P
>>
>> It *isn't* hard. I've filed many bugs over the years, and it isn't the
>> oh-so-difficult process you seem to think it is -
>
> The account setup process seemed tortuously difficult to me. I spent a
> full two weeks trying to work around the problem before I finally gave
> up and tried to file a ticket.
Maybe rather than calling it "tortuously difficult", a better
terminology would be to say that it scares people off.
I'd totally agree with that, and maybe it might help Jim understand your
point.
A signup process asking for more than absolutely necessary (i.e. a valid
e-mail address, an alias and a password) /is/ scary for some people -
and yes, dealing with scary things /is/ difficult for some people.
Sometimes to the extent that they rather suffer two more weeks of trying
alone.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2015-03-19 16:45, Orchid Win7 v1 a écrit :
> Perhaps you're missing the part where I actually *did* all this to file
> a bug (which, last I checked, is still open). Basically Zypper gives you
> an incorrect error message - but apparently Zypper just tells you what
> Curl tells it. So until Curl gets fixed...
>
Have you contacted the curl maintainers?
>>> You know what's *really* annoying? Seeing an open bug for THE EXACT
>>> PROBLEM that our production application has, seeing that upstream has
>>> fixed it, and yet OpenSUSE refuses to release an RPM for it. *That* is
>>> annoying! (We're talking about a different bug now. The ticket has been
>>> open for many months. The fix is literally to build a new RPM. Yet it
>>> isn't happening...)
>>
>> Example? Because for that bug, I'd like to nudge someone, or at least
>> find out why.
>
> In OpenSUSE 13.1, systemd hangs for 60 seconds on shutdown. It's waiting
> for... I forget what it is now, but after 60 seconds it gives up and
> shuts down anyway. It just means every time you want to shut your PC
> down, you have to needlessly wait 60 seconds before it does it.
>
> The bug is fixed in systemd 209 (?), but the latest official RPM from
> OpenSUSE is 208, which doesn't contain the fix. (There was some talk
> about the upstream "fix" being a bit of a kludge... I'm not sure exactly
> how true that is. I just want the bug to go away.)
>
> Somebody filed a ticket. Somebody else said "here, try this RPM and let
> me know if that fixes it". The original poster never let anybody know if
> it worked. Ticket is currently set to "waiting for information" or similar.
>
Maybe the proposed fix make his pc open a gate the to eight dimension,
and the person was never seen again? If I was in charge of QA, I'd be
reluctant to release said RPM lest I be sure that it won't make dameons
fly out of someone's nose.
(oh, and either switch newsreaders, or stop deleting the "XXX wrote:"
lines at the top. It makes it difficult to follow who said what)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Mar 2015 20:45:35 +0000, Orchid Win7 v1 wrote:
>>> Well, maybe they shouldn't actively dissuade people from filing bugs
>>> by making it so sodding hard to file a bug? :-P
>>
>> It *isn't* hard. I've filed many bugs over the years, and it isn't the
>> oh-so-difficult process you seem to think it is -
>
> The account setup process seemed tortuously difficult to me. I spent a
> full two weeks trying to work around the problem before I finally gave
> up and tried to file a ticket.
*headdesk*
It seriously is not that difficult. You go to the site. You create an
account, provide information (true or fake information, doesn't matter),
validate e-mail address, authenticate to Bugzilla, and enter your bug.
It ain't rocket science.
>> based on exactly ZERO experience doing so.
>
> Zero experience?
>
> Perhaps you're missing the part where I actually *did* all this to file
> a bug (which, last I checked, is still open). Basically Zypper gives you
> an incorrect error message - but apparently Zypper just tells you what
> Curl tells it. So until Curl gets fixed...
Bug number?
>>> You know what's *really* annoying? Seeing an open bug for THE EXACT
>>> PROBLEM that our production application has, seeing that upstream has
>>> fixed it, and yet OpenSUSE refuses to release an RPM for it. *That* is
>>> annoying! (We're talking about a different bug now. The ticket has
>>> been open for many months. The fix is literally to build a new RPM.
>>> Yet it isn't happening...)
>>
>> Example? Because for that bug, I'd like to nudge someone, or at least
>> find out why.
>
> In OpenSUSE 13.1, systemd hangs for 60 seconds on shutdown. It's waiting
> for... I forget what it is now, but after 60 seconds it gives up and
> shuts down anyway. It just means every time you want to shut your PC
> down, you have to needlessly wait 60 seconds before it does it.
>
> The bug is fixed in systemd 209 (?), but the latest official RPM from
> OpenSUSE is 208, which doesn't contain the fix. (There was some talk
> about the upstream "fix" being a bit of a kludge... I'm not sure exactly
> how true that is. I just want the bug to go away.)
>
> Somebody filed a ticket. Somebody else said "here, try this RPM and let
> me know if that fixes it". The original poster never let anybody know if
> it worked. Ticket is currently set to "waiting for information" or
> similar.
I didn't see that issue on my 13.1 systems, but now run 13.2, however, if
the fix is a bit of a kludge, then I can see why the devs wanted to wait
for a real fix from upstream.
>>>> Not sure what you mean by "show task list option". What was the
>>>> specific thing you were trying to do?
>>>
>>> The option to have an icon for each window that's open, so you can
>>> instantly switch between windows (or just tell when a hidden window
>>> closes itself). You know, like the Windows taskbar.
>>
>> Oh, like the dash-to-dock extension gives you. Yeah, that extension is
>> one that I use, and it works great.
>
> I, too, eventually found an extension that could be configured to behave
> in a suitable manner. It just annoyed me that this is some unsupported
> 3rd-party hack, rather than part of the basic functionality of the
> shell.
Submit an enhancement request, then. Unless you find logging into a
website to be a bit too difficult to manage. The proper place would be
the GNOME3 bug tracking system (or enhancement request system).
>
>>> Well, I don't know man. Version 2 of a product has a heap of features
>>> which are gone in version 3. To be, that means that version 3
>>> *objectively* has fewer features. I didn't think there's much to argue
>>> about that...
>>
>> I used GNOME2, and I use GNOME3. Both did the job I needed, so I don't
>> really care if there are "fewer features", because features I don't use
>> are unimportant to me. Hence, personal preference.
>
> I would have thought "seeing what windows are open and moving windows
> around" is a pretty core functionality to a window manager. But
> apparently your mileage is different...
I can see what windows are open, and I can move windows around. I do
that every day, so I don't know what you're on about here.
>> So no, you didn't ask for help, yet you complain about not being able
>> to get help. That's telling.
>>
>>> In seriousness: I asked on Stack Overflow. The question was upvoted
>>> several times, and many other people lamented the utter lack of any
>>> documentation. But nobody actually answered the question. Which is
>>> what happens when nobody knows the answer!
>>
>> One venue, where GNOME development isn't a primary discussion topic,
>> does not mean "nobody knows the answer". Except in your world, it
>> would seem.
>
> Stack Overflow is only the single largest place to get help about any
> programming problem you might have. If not one single person who
> happened upon a GNOME question explicitly flagged with the GNOME tag
> knows how to do a thing, it can't be that well-known. (And if it *was*
> well-known, surely there wouldn't be so many people up-voting the
> question. Rather, they'd be saying "dude, read the manual, it's right
> here!")
I'll let you in on a little secret: Not everyone with expertise has time
to read a million different forums. When a project has its own forums,
use those rather than third party forums. Choosing an appropriate venue
is important.
See http://catb.org/~esr/faqs/smart-questions.html for why that's
important.
>>>> And "deleting code from the running system" isn't the same as
>>>> extending it.
>>>
>>> From what I've seen, you write extensions by deleting existing
>>> objects
>>> and replacing them with new ones. (Or maybe just replacing a method or
>>> two.) You'd think it works by creating a new object that exposes a
>>> defined set of operations, and passing that to the framework. But no,
>>> it seems you just put your hands in the framework, rip out the bits
>>> you don't want, and then replace them.
>>
>> Overriding is not the same as "ripping out the bits you don't want and
>> replacing them". You should know that from your study of OOP methods.
>
> Thing is, when you override a method, you're not destroying the old
> implementation. You're creating a new class that works differently.
> Anybody using the old class still gets the old behaviour. This is
> different; you're dynamically deleting the code from the system while
> it's still running - potentially even while somebody is trying to *call*
> that code!
>
> I mean, it *works* and all... It just seems like a pretty scary design.
I don't know for sure, but I think you'll find the underlying code is
actually still there when an extension is installed - you're just hooking
around it.
>>> And then watch it all break horrifyingly in the next minor-release of
>>> the shell.>_<
>>
>> If you refuse to find the right venue to ask for help, then you kinda
>> get what you deserve there.
>
> I'm talking about all the extensions that *other* people wrote which
> break on later versions of the shell. (My own extension actually
> survived - mostly because it barely does anything.)
Well, here's a shock - when you upgrade a piece of software, stuff that
depends on the software you upgraded might not work properly. That's
only the way things are with *every single piece of software used as a
foundation for some other piece of software on the planet*.
>>> Still, IMHO, I think most of this brokenness goes back to "we decided
>>> to build a huge, complex application in a scripting language". All
>>> problems flow from there.
>>
>> Now there's something I might be able to get behind.
>
> Somehow I doubt the GNOME foundation are going to change it tho. ;-)
So then the alternative is to deal with it, if you have to, or don't, if
you don't.
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 20 Mar 2015 09:23:27 +0100, clipka wrote:
> Am 19.03.2015 um 21:45 schrieb Orchid Win7 v1:
>>>> Well, maybe they shouldn't actively dissuade people from filing bugs
>>>> by making it so sodding hard to file a bug? :-P
>>>
>>> It *isn't* hard. I've filed many bugs over the years, and it isn't
>>> the oh-so-difficult process you seem to think it is -
>>
>> The account setup process seemed tortuously difficult to me. I spent a
>> full two weeks trying to work around the problem before I finally gave
>> up and tried to file a ticket.
>
> Maybe rather than calling it "tortuously difficult", a better
> terminology would be to say that it scares people off.
>
> I'd totally agree with that, and maybe it might help Jim understand your
> point.
>
> A signup process asking for more than absolutely necessary (i.e. a valid
> e-mail address, an alias and a password) /is/ scary for some people -
> and yes, dealing with scary things /is/ difficult for some people.
> Sometimes to the extent that they rather suffer two more weeks of trying
> alone.
I understand his point completely. His point just isn't valid - it's not
tortuously difficult to create an account. You fill in information,
submit the form, get an account. Nobody says the information has to be
valid (other than the e-mail address, which is sensible).
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> If it were just my home PC, I'd probably assume that something is wrong
> with my PC. Given that the PC at work does the exact same thing... and
> other people in the office have also mentioned it and switched
> browsers... I suspect it's not just me.
So please explain why it works just fine with my PC.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2015 06:38 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> If it were just my home PC, I'd probably assume that something is wrong
>> with my PC. Given that the PC at work does the exact same thing... and
>> other people in the office have also mentioned it and switched
>> browsers... I suspect it's not just me.
>
> So please explain why it works just fine with my PC.
Absolutely no idea. What version are you running?
(As I said, I ran a much older version in a VM, and it was trippy-fast.
It's only recent versions that seem slow...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/03/2015 08:08 PM, Orchid Win7 v1 wrote:
> So I installed Opera, and I've just spent about an hour trying to force
> it to work the way *I* want it to work, not how it tells me I should
> work.
So today I learned a thing: Opera auto-updates itself. And it is
impossible to disable this behaviour.
I don't find that very amusing.
(Well OK, it's but *impossible*, just damned hard. There's a
command-line switch --- which won't work if you click a URL which
auto-opens the default web browser. Or you can rename the updater
executable. Which may accidentally get "repaired". Or you can try to
firewall your web browser... good luck with that!)
Not only can you not tell it to stop this, you also cannot tell that
it's doing this. There's no UI to tell you an update is happening, or
how far it's got, or anything. That's very annoying.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/04/2015 07:17 PM, Orchid Win7 v1 wrote:
> So today I learned a thing: Opera auto-updates itself. And it is
> impossible to disable this behaviour.
>
> I don't find that very amusing.
Could be worse, I suppose; FileZilla auto-updates itself too. It has an
option to turn off updates, WHICH IT BLATANTLY IGNORES!
As in, I've turned updates off, the settings dialog tells me it's off,
and still every time I start the program it prompts me to install the
update. And no matter how many times I delete the update file, it
redownloads it again.
Maybe it's time to switch to WinSCP...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|