Need Help with Office politics
-
I foolishly assumed "new" to mean "new".
Again, semantics. It's a clone of the original one. In a metaphysical sense, is it really new? In fact, it's probably implemented by copy-on-write, so it's actually literally the same one at first.
If you weren't so reflexively argumentative it would probably help.
-
You start with one thing, and you duplicate it, and now you have a new thing.
Copy on Write means you actually only have one--at first. I don't know the actual implementation details, but you have a set of bookkeeping details (the "process" object in the kernel or whatever) that points to the same set of pages--again, at first. Later, at some unspecified point, the bits need to become different, so they are copied then, and only at that point are there really two hunks of memory. (At least, that's how I think it works.)
-
Again, semantics. It's a clone of the original one. In a metaphysical sense, is it really new? In fact, it's probably implemented by copy-on-write, so it's actually literally the same one at first.
If you weren't so reflexively argumentative it would probably help.
My contention is that what really matters is the overhead created by the second object. If it's a simply mirror, versus if it invokes initialization, would seem to matter a lot.
-
Who were generally the people who thought of themselves as power users
That's actually hilarious, when you consider it--it means they didn't invest enough brainpower in remembering where shit is.
I have, probably, half a dozen apps I use on a day-to-day basis at work. Now some of them I have multiple instances of, that connect to a different database, or whatever. Most of them I just pin to the desktop or taskbar and am done with it. I can actually go days without going to the start screen.
I hated the screen at first. Then I discovered how to use it and my attitude changed. It has its warts, but on balance I really do think it's better.
-
The crippling was a feature, not a bug.
I never said it was a bug. But to me--and probably to a lot of people--it made it harder to use. Especially since they deprecated personalized menus because nobody liked them in Office 2000 or wherever they were introduced! Those, at least, didn't have the limits of the post-XP FUL.
-
Just simply no way to make that work in the Vista/7 start paradigm, unless your start bar is like 3 rows tall.
Right--that was why I said they crippled it.
-
You do realize they come in like 3 sizes, right?
To be fair, that's not terribly discoverable, and I don't think it worked in 8--wasn't it new in 8.1?
-
- 5 most common programs get pinned to the taskbar.
- The next most common programs/files get shortcuts on the desktop. This is somewhat organized with folders on the desktop, such as games and "work related". This keeps me down to about 10 shortcuts on my desktop. Office files in this category also get pinned to their respective program's "Recent Files" menu.
- Frequently used programs/utilities get pinned to the start menu. No more than 4.
Mine's more or less this, except rather than pinning to the start menu they end up in the frequent programs list anyway.
-
FTFY.
Oops. How the heck did I do that?
Also, I'm assuming the Unix model here because [reasons].
Oh, I agree. You can port Unix-style stuff--sometimes, and to some extent--but if you want to write code for Windows, you should do it the "right" way for Windows. That does mean you have two different paradigms. You can be like some people[1] and rage endlessly about that or you can just accept it.
[1] No, I didn't mean anyone here.
-
The next most common programs/files get shortcuts on the desktop. This is somewhat organized with folders on the desktop, such as games and "work related".
Stardock might be for you, with its desktop groups.
Obviously I'm replying to @abarker here, not @loopback0, but I chose to hit reply to the latter's quote of the former, not go back to find his original post.
-
My contention is that what really matters is the overhead created by the second object.
That's probably true. I wonder if Unix-style fork() apps pause when the copy happens? Probably not, because it's just a memcpy() and not a fresh read off disk.
-
https://www.youtube.com/watch?v=2-q61wbWm3c
If my Google-fu hasn't let me down, it looks like as of W8.0 the tiles were resizeable for metro-based apps only (but not for the non-metro ones). The images on the linked video were all medium sized for the non-metro ones.
-
That could be right. I've got 8.1, though, so I can't verify. In .1, you can definitely resize desktop app tiles.
-
my organization goes pretty much as follows
This is not much different from mine, except I have a dozen common programs pinned to the taskbar (and I start most of them as soon as I log in): task manager, calculator, email, VNC viewer, VCS client, Explorer, web browser(s), ordered by the number of windows I tend to have open, so the positions on the taskbar stay somewhat stable. (And I have the taskbar sized 3 rows high.)
There are a bunch of shortcuts on the desktop, but I never use them because they are always buried under 42 windows; the only time I see them is right after I reboot.
I only pinned a couple of things to the start menu (although there are three others that were pinned by their installers, and I haven't bothered unpinning; a couple of those are also pinned to the taskbar) — things I don't necessarily use all that often, but when I want them, I don't want to have to go searching for them, like Character Map.
Most of the other stuff I use, I use often enough that they are in the start menu's list of recent programs. Otherwise, → All Programs. As @tarunik wrote, "most of my windows experience is on XP, which predates [the Win+Search] shortcut."
-
You can port Unix-style stuff--sometimes, and to some extent
There's enough POSIX in NT that Services for Unix works; not all of it is seen by the W32API layer though. A good example of this is the proof-of-concept
fork()-alike that's sometimes seen alongside discussions ofNtCreateProcess().but if you want to write code for Windows, you should do it the "right" way for Windows. That does mean you have two different paradigms.
Aye -- Windows made some decisions back before Windows servers were a thing that made threading the "right" way to do parallelism on WIndows.Keep in mind, also, that Unix boxes were serving up files, news, mail, and all sorts of other things well before Windows NT came of age...
-
Keep in mind, also, that Unix boxes were serving up files, news, mail, and all sorts of other things well before Windows
FTFYNT came of age1.0 existed.
-
Keep in mind, also, that Unix boxes were serving up files, news, mail, and all sorts of other things well before Windows NT came of age...
... and therefore it's better at it in 2014?
-
Sorry; I foolishly assumed "new" to mean "new". Obviously my own error, assuming words have meanings
Yes, they do, but you also said, "start up a whole new Python interpreter." But it isn't really starting up. It's fully formed and doing stuff. It doesn't have to read in source code or libraries or even the interpreter's code, because it's already there.
Depending on the OS, it may not even actually copy the memory (if it uses copy on write) though it gets its own address space, of course.
-
Sorry I don't know the terminology, because I didn't use it much until I trashed my Macs, but Obj-C had this visual layout programming tool thing that let you link the output of shit to the input of other shit, so you can tell your program stuff like, "if cursor is in text field enable Cut menu command" without writing any code. That's a dumb example, but you could hook it to like data objects and data objects to like DB tables and such, it was actually pretty powerful.
Something like this?
http://i.imgur.com/GxKX476.png
Unfortunately, no binding to data sources and all that fancy stuff AFAIK, which is a shame. Looking at the generated code, I'm assuming it's a limitation of UI file format (which is XML as well), since all widgets that display data in Qt need to be connected to a proper C++ model.
RE: pinning stuff, kudos to MS for that. I love it on Windows (on rare occasions I use it), and used to use DockbarX on Gnome 2. I'm using a dock now since I still haven't found a decent replacement for it. Then again, I just found this thing for Gnome Shell... Damn it, does that mean I have to give it another chance now?
While on the subject of Gnome Shell, I quite like the way it's applications menu works and looks:
http://upload.wikimedia.org/wikipedia/commons/0/0e/Gnome_Shell_Applications_Screen.png
The categories are still there, search works well, though icons still take up too much space for my taste, but I think that's configurable.
I personally find the huge tiles in Windows 8 a waste of space. The search view is pretty good. I think that if (on desktop, not tablet/phone) they just opened the search view by default and stuck the live tiles where categories are in the Gnome Shell screenshot above it would work rather well, and there would (possibly) be a lot less complaining. Which they kinda are now with 10 cramming live tiles into the start menu...
-
[s]Depending on the[/s]On a non-ancient OS, it [s]may[/s]does not even actually copy the memory ([s]if[/s] it uses copy on write) though it gets its own address space, of course.
FTFY. Non-copy-on-write
fork()implementations are an endangered species now -- the only one I have even heard of is Cygwin's, and that's not something we should even care about for the purposes of this discussion.Yes, they do, but you also said, "start up a whole new Python interpreter." But it isn't really starting up. It's fully formed and doing stuff. It doesn't have to read in source code or libraries or even the interpreter's code, because it's already there.
QFT, because a Like isn't enough. Apparently blakey has no B*****ming clue howfork()actually works, and just buttumes that it behaves exactly likeCreateProcess(); it doesn't.... and therefore it's better at it in 2014?
"Better?" I wouldn't go that far, not without qualification at least: NT isn't a total historical ignoramus. HOWEVER, Unix-land has had more experience with the server environment than Windows-land -- and that experience includes the point I'm making, which is "how to run a production server without thread-based (i.e. single address space) parallelism".Anyone care to dig a VAX-11/782 out of storage just to show blakey that multiprocessor systems were a thing back in that era?
-
FTFY. Non-copy-on-write fork() implementations are an endangered species now
I suspected as much, but I didn't know, so I went with the safe wording. And I'm sure some dickweed would have come up with a modern RTOS or some other shit that "proved" me wrong.
-
Anyone care to dig a VAX-11/782 out of storage just to show blakey that multiprocessor systems were a thing back in that era?
Look, you're really missing the point here, to a ludicrous degree.
History's interesting and all, but the point is, if I'm buying a webserver today, what does Unix do better than NT today? Sure I concede Unix was better at it in 1992. Woot. Who gives a shit. It's not relevant.
-
Microsoft announced today they're open-sourcing almost all of the .net stack, including the compiler and web server components. This is a good move, it'll guarantee Mono is up to snuff on Unix-based OSes (including the Macs those trendwhores run), and remove a major reason for people feeling wary about using .net in projects. ("But then don't we get locked-in to MS servers?")
-
Look, you're really missing the point here, to a ludicrous degree.
No, you're missing my point, which is that you can have multi[i]tasking[/i] and even multi[i]processors[/i] with[i]out[/i] using same-address-space threading -- a point you completely missed when you said:
Then wouldn't you be on the same CPU and the same Python virtual-bullshit-made-up-threadpool?
and
Seriously? "We don't have proper threads, so fork the process and start up a whole new Python interpreter" is the solution here?
On the other hand:
@blakeyrat said:History's interesting and all, but the point is, if I'm buying a webserver today, what does Unix do better than NT today? Sure I concede Unix was better at it in 1992. Woot. Who gives a shit. It's not relevant.
is completely irrelevant to the point I'm making, which, again, is that Unix servers (including symmetric multiprocessors) operated for years without a notion of thread-based parallelism, so to sayThen wouldn't you be on the same CPU and the same Python virtual-bullshit-made-up-threadpool?
shows a deep-seated ignorance of how processes work.
-
No, you're missing my point, which is that you can have multitasking and even multiprocessors without using same-address-space threading -- a point you completely missed when you said:
Right; by spawning other processes. I get that.
The reason I typed this:
Then wouldn't you be on the same CPU and the same Python virtual-bullshit-made-up-threadpool?
Is because you originally said you could have multiprocessing in Python from only one interpreter.
What I didn't know is, in your little warped brain, if you take one interpreter and clone it, you (apparently) still only have one interpreter. That was my confusion.
shows a deep-seated ignorance of how processes work.
No, it shows my deep-seated ignorance of:
When tarunik says a single Python interpreter can run in two processes, he's a crazy-person who is confused as shit and is confusing everybody else-- what he actually means is he created a clone of the Python interpreter.
We're not talking about a technical misunderstanding here. At no point have I been fuzzy on any technical concepts, as it turns out. (I thought I was, back when I thought you were saying a single Python process could simultaneously run on multiple cores, but it turns out you were confused on that point.)
In short, it's not my fault you typed this:
You can fork without starting up a new interpreter, even in Python.
And confused the bejeezus out of everybody.
-
And confused the bejeezus out of everybody.
That's a strange definition of 'everybody' you have there, as FrostCat got my point:
Do you really want to argue semantics? Yes, a new process is created, but nobody, as he said, explicitly calls exec("/usr/bin/python") or whatever.
My contention is that what really matters is the overhead created by the second object. If it's a simply mirror, versus if it invokes initialization, would seem to matter a lot.
This is what I was trying to get at here. If I set a breakpoint in
Py_Initialize()and then the Python code the interpreter runs callsos.fork(), does that breakpoint get hit again? No!
-
I'd still feel better about Python if it had real threading, and its library wasn't full of broken obsolete junk. Oh, and if they'd gotten the core library right on the first try instead of needing "urllib3". And if they hadn't totally fucked-up the upgrade to Python 3... Python has a lot of problems, basically.
-
I'd still feel better about Python if it had real threading, and its library wasn't full of broken obsolete junk. Oh, and if they'd gotten the core library right on the first try instead of needing "urllib3". And if they hadn't totally fucked-up the upgrade to Python 3... Python has a lot of problems, basically.
It has a mild PHP infection.
-
As to the library issues -- I'm sure that these problems are nothing that Perl, .NET, or Java don't face, both in terms of having badly-designed core library parts that they can't shed because of backwards compatibility and broken, obsolete junk laying around the package archives.
The Python 3 upgrade is an interesting case, though -- there is something to be said for 'getting all your incompatible changes out of the way at once', and it does seem to be moving at a decent clip now that the major Python projects (as in Django etal) are supporting it, and Linux distros are starting to push out Python 3 as the system Python interpreter.
Feel free to throw "Blakey's Python 3 migration plan" up here, though, given that Python 3 makes backwards-incompatible changes to the language -- otherwise, they wouldn't have needed it, and the 2.x sequence would have continued unabated.
-
As to the library issues -- I'm sure that these problems are nothing that Perl, .NET, or Java don't face, both in terms of having badly-designed core library parts that they can't shed because of backwards compatibility and broken, obsolete junk laying around the package archives.
.net certainly doesn't have it, at least for bog-standard mainstream protocols like SOAP. .net definitely wouldn't have implemented one and then let it slowly break over a few years of changes elsewhere. I can't speak for the other languages you list.
The problem is the Python open source-y developers are all out there writing "fun" code, and they don't have anybody saying: "ok guys, sure this Python physics simulation is 'fun', but our platform still lacks a fucking SOAP library that works-- how about we get the work out of the way first, huh?" Because it's too open source-y.
Feel free to throw "Blakey's Python 3 migration plan" up here, though,
Ok but it involves a time machine.
The funny thing is, I was working in 2.7. (I think? Whatever the latest non-3.x version was last March.) And I found a ton of broken incompatible shit in the libraries. So Python had a backwards-compatibility problem long before 3.x came out, apparently.
-
bog-standard mainstream protocols like SOAP.
As far as I'm concerned, SOAP is the weirdo -- now if the HTTP libraries were all broken at the level you described, that would be cause for concern!
And I found a ton of broken incompatible shit in the libraries. So Python had a backwards-compatibility problem long before 3.x came out, apparently.
I suspect the code you were dealing with was broken all along...
-
The funny thing is, I was working in 2.7. (I think? Whatever the latest non-3.x version was last March.) And I found a ton of broken incompatible shit in the libraries. So Python had a backwards-compatibility problem long before 3.x came out, apparently.
I work in 2.7 professionally and 2.4 on a personal site, and there were definitely a ton of breaking changes between those versions.
-
now if the HTTP libraries were all broken at the level you described, that would be cause for concern!
Really? Didn't I just mention the presence of at least 3 versions of "urllib" like 3 posts ago?
I hate to break this to you, but HTTP libraries were all broken. That's why they're on version 3 of the damned thing. They had to start over to get it right. TWICE.
I suspect the code you were dealing with was broken all along...
Indeed a possibility, but hardly something that attracts developers to the platform. "The library repository is full of broken shit that didn't work even when uploaded!" Gee, thanks.
-
Really? Didn't I just mention the presence of at least 3 versions of "urllib" like 3 posts ago?
I hate to break this to you, but HTTP libraries were all broken. That's why they're on version 3 of the damned thing. They had to start over to get it right. TWICE.
I was saying 'broken' as in doesn't even work with a current Python. Just because urllib3 exists doesn't mean that urllib or urllib2 were utterly broken, its just that urllib3 is improved in a way that they couldn't do with the existing urllib or urllib2.
Indeed a possibility, but hardly something that attracts developers to the platform. "The library repository is full of broken shit that didn't work even when uploaded!" Gee, thanks.
There were some breaking bugfixes between 2.4 and 2.7 -- but I'd say that there's also a large "Works For Me!" component floating around as well, especially with an unholy horror such as SOAP -- the author wrote something that digests the SOAP they ran into, but that's nowhere near what you're dealing with because the spec is made of pure brokenness.
-
I'd still feel better about Python if it had real threading
Probably everyone who's not a python groupie feels that.
-
.net certainly doesn't have it, at least for bog-standard mainstream protocols like SOAP.
This is probably because they watched Java. You could see a hint of that with the Windows Foundation Classes, which rather obviously later became the core of the .Net library.
-
it took me a few days to figure out how to reliably get out of an app into the desktop.
I've been using 8.1 for less than a week now, and I've found:
- mouse to top right corner, find the desktop live tile type thing
- mouse to the top of the screen and use the minimise/close buttons
- mouse to the top of the screen, drag the top bar to the bottom and release to close
-
also works:
- ALTF4
D
-
See, I found clicking the top left corner of the screen, where there's no button or anything but clicking there works.
-
I haven't been given much work to do yet, since they seem to think I'll be slower at the training exercises, so I've been fiddling. Compared to some of the horror stories I've heard, it's not that bad at all. I'm not sure I would have enjoyed 8.0 as mugh though
-
that works too. there is a button there, but click routing gets weird. if there is no click handling screen element there then the hidden system button gets it as if it was visible.... I'm not sure i like that feature. if the mouse stays at the top of the screen long enough then it shows the buttons and they take precedence over app UI buttons....
I'm becoming less a fan of MetroUI. maybe Win10 can rescue it
-
ALTF4</
If the top right corner thing is the equivalent of Expose on Mac / Scale on most Linux DEs (that support it) I use that quite a lot actually. Easier to find a window if I have a whole mess of them, or close them by middle clicking. Especially if I have multiple instances of the same application (mostly the file manager or terminal) since they get grouped in my dock.
Also, I mostly tend to forget which workspace I left them on, so scaled workspaces view also helps :P
-
Well, 10 is moving apps into normal windows (if you so choose), which has some advantages.
@Yamikuronue: Other options include moving the mouse to the top left, then sliding it down to show all open 'apps' (which includes the desktop if you've opened it) or just pressing the windows key and clicking on the desktop tile.
My desktop is on Win8 Enterprise, because I had MSDN access at the time. I will never even consider installing Enterprise again... I can't update to 8.1.
-
-
All you have to do to update to 8.1 Enterprise is to get the installer and do a (fully supported) in-place upgrade from within your running Windows 8 installation. A deliberate design choice to give enterprises better control over the deployment of such a potentially breaking update.
-
When I was looking online, no one could explain how. Because I no longer have an MSDN account, there may be issues with the upgrade. I'm planning on formatting soon after I buy a new CPU, which shouldn't be long now.
-
Basically, Microsoft requires the following to go from 8.0 Enterprise to 8.1 Enterprise:
- Download or otherwise acquire a ISO for 8.1 Enterprise installation
- Insert the DVD/USB disk with 8.1 burned on it while your computer is running in the 8.0 Enterprise partition
- Select "Install Windows" and choose the Upgrade option -- basically, just like a new install, except you choose Upgrade instead of Custom and don't lose data or installed programs or anything.
- Let Windows install, then run your updates and be happy.
But hey, it's the first ever officially supported "in place upgrade" by Microsoft!
-
Meh. Haven't formatted in a year or two, and it will give me a chance to buy an SSD and prioritize which files I actually want on my machine. Plain ol' 8 is certainly good enough for now.
-
But hey, it's the first ever officially supported "in place upgrade" by Microsoft!
Is that true? I think they supported 95 -> 98. (And of course 98 -> 98se, if you count that.)
Not sure about any of the NTs, though. I think it their setup program claimed to do 2000 -> XP, but I'm not sure whether it was actually supported or just thrown-in.
-
But hey, it's the first ever officially supported "in place upgrade" by Microsoft!
pretty sure that's not right ...
Yeah, found this pretty easy:
When you use the Upgrade option, your files and applications are maintained on the computer and do not need to be reinstalled. The Upgrade option is available in Windows 7 Setup for some computers running Windows Vista®.1
The "some" basically excludes cross-architecture upgrades, upgrades from Vista Starter, and a few other unsupported scenarios2.
Like @blakeyrat said, there may have been earlier cases, but I've already shown you're wrong, so I'm done.
