I just built a gaming PC 2 weeks ago, and got Windows 8 because i couldn't be bothered chasing drivers for new hardware on the old OS. Sure, I could, but I couldn't be arsed. I usually run a mac these days. I've been running 8 on and off since the beta at work.
Having spent a good amount of time with it now.... I'm still pissed with the start screen. It is pointless on a desktop, not customizable enough, metro apps don't do anything useful, whenever i try to play a video with double click it wants to open in metro, despite me perhaps wanting to run in a window. Hot corners can stay, they're half decent, at least on a single monitor.
Other than that, my file copy performance between it and FreeNAS has gone to absolute shit via SMB.
All in all? Serves its purpose as a game loader. It's a shitty OS, despite some technical improvements in the kernel, the UI just gets in the way.
Facebook is becoming a platform. Games are made for it, people use it to chat, send messages, etc. So long as a device runs facebook, there's a massive market there for it, whether it runs windows, linux or whatever. Microsoft don't want that - they want people to use services dependent on windows.
Actually a large part of why apple is profitable is due to their supply chain. Yes, it's boring non-sexy shiny stuff, but there's a reason apple offer very limited customization and it is largely due to getting economy of scale so they can increase their margins.
Vista was actually fine if you had half recent hardware of a sane spec to install it on. The BIG issue with vista was the marketing clusterfuck and lack of driver support. But hey, i went through the lack of driver support for a while with Windows 2000 Professional. The OS itself was pretty solid. The fact that Windows 7 and 8 are mostly vista at their core is testament to that.
Given that the spec says this is a MINIMUM value, then I'd say the misinterpretation is in Linux - by hard-coding in 10ms and attempting to use devices after that. As per TFA, an interrupt is generated by an xHCI controller when the device is ready to use again. So, blindly attempting to use the device again after 10ms is breakage in LINUX.
I'd also say that the USB spec is written in a pretty broken way to cause said confusion, but that's a whole new issue.
I suspect they wont immediately. More likely they will cut costs and instead of having 4 or 8 cores on your CPU, you'll have ONE, just clocked higher. a single core is a LOT less complex to program for, and it will run fast enough that it doesn't matter for some time. ditto for GPUs. I suspect you'll see the designs simplified, consuming less power, etc long before we see similar complexity designs to today on graphene.
A major reason is that the software just isn't there yet.
Maybe, maybe not. Intel have been hinting that they won't be using silicon for much longer, a couple of years back they said there was maybe 3-4 generations of CPU left that they were going to do in silicon and that they had something "Really cool" in the lab to replace it with.
And I've got windows VMs that haven't had a reboot in over 6 months as well. What's your point? The only need to take the machine down is for scheduled updates that can't be mitigated by other measures in the meantime. Given the vast majority of issues appear to be browser problems or GUI issues when logged into the machine (and my servers are pretty much never logged into) then I can quite happily not run windows update every patch tuesday and still remain safe.
Correlation != causation. I agree most existing graphical programming environments are shit. But I don't believe it is a result of them being written in a graphical editor inherently. It's a case of getting that environment right being a hard nut to crack. Given that you can represent pretty much any program via flow diagram, the info is all there. It's just a case of someone writing a re-usable component library properly.
Also, there's an old saying in computer science: computing time is cheap. programmer time is expensive. Unless you are dealing with problems that NEED massively powerful CPU because every cycle counts, you're better off writing stuff in a higher level language to make it easier on the programmer and throw CPU/RAM at the problem. If your high level program gets the job done in an acceptable time frame, there's ZERO point in writing it in a more error prone low level language. If it DOESN'T run in an acceptable time frame, the 90:10 rule means you spend your effort optimizing the 10% of the code where the hotspot is and leave the rest high level.
I'd say the cause of programs getting slower and buggier is due to the inadequate teaching and the pressure from the accounting department - nothing to do with the choice of language really.
Oh don't get me wrong, I totally agree. We have a plague of access databases here that engineers have written that have become mission critical.
My point is that this is a symptom of there being a lack of a decent alternative - and before someone mentions SQL again, this is not an equivalent product. Sure they're both database engines, but what sets access apart is the ease of building a UI and glue logic around the database.
MS/other need to replicate that sort of functionality before a heap of people will dump access.
And in between the coding and the spec is the analysis which fleshes out the data and logic flow. Typically visually. Which is as hard as programming needs to be with an appropriate object library.
Exactly. And given that an entire program's flow, data inputs/outputs/etc can be captured in a flow diagram, this is about as hard as programming NEEDS to be for most apps that can re-use high level component objects. Which is pretty much most applications people want to use to get jobs done.
Not really. Pretty much all your glue logic in a typical program to tie the blocks together could be done visually. There's nothing magical about programming in a high level language that necessarily requires the vast majority of it to be done in a text editor.
Sooner or later programming is going to go this way and to be honest, the sooner the better. The computer is meant to make life easier on its users to get a sequence of steps done. All learning a specific textual language does is place a barrier to entry in the way of the user.
Yes there are specific niches where you'll need to go into low level code, but most of the apps people want to use to get stuff done aren't like that.
I think this is is an indication that MS (or someone else) should fill the huge hole in the market for a product LIKE Access to use, which isn't crap. SQL server is not the same thing, and it is nowhere near as easy to prototype a database driven application in SQL as it is in Access.
The fact that many people (including myself) use access from time to time to quickly solve problems in an hour or so (my most recent use was a decoder database for Windows IAS logs) that would take far longer than that to even create the back end tables and relationships in SQL DESPITE the suckage should be a massive hint for someone to put out an equivalent that DOESN'T suck.
So because you saw some old app fuck over a client who is too stupid to back up, your servicing experience with your car was less than spectacular?
If software does the job with a minimum of fuss, it is fit for purpose. Re-implementing the wheel "just because" is a waste of time, resources and will increase the cost of your servicing to pay for it.
Its double the cost of x86 hardware in terms of RAM and CPU. CPU is generally abundant; you already have multiple hosts in your cluster anyway. You can limit it to VMs that really need to be up, only.
Slashdot Mirror
I just built a gaming PC 2 weeks ago, and got Windows 8 because i couldn't be bothered chasing drivers for new hardware on the old OS. Sure, I could, but I couldn't be arsed. I usually run a mac these days. I've been running 8 on and off since the beta at work.
Having spent a good amount of time with it now.... I'm still pissed with the start screen. It is pointless on a desktop, not customizable enough, metro apps don't do anything useful, whenever i try to play a video with double click it wants to open in metro, despite me perhaps wanting to run in a window. Hot corners can stay, they're half decent, at least on a single monitor.
Other than that, my file copy performance between it and FreeNAS has gone to absolute shit via SMB.
All in all? Serves its purpose as a game loader. It's a shitty OS, despite some technical improvements in the kernel, the UI just gets in the way.
Facebook is becoming a platform. Games are made for it, people use it to chat, send messages, etc. So long as a device runs facebook, there's a massive market there for it, whether it runs windows, linux or whatever. Microsoft don't want that - they want people to use services dependent on windows.
Actually a large part of why apple is profitable is due to their supply chain. Yes, it's boring non-sexy shiny stuff, but there's a reason apple offer very limited customization and it is largely due to getting economy of scale so they can increase their margins.
Vista was actually fine if you had half recent hardware of a sane spec to install it on. The BIG issue with vista was the marketing clusterfuck and lack of driver support. But hey, i went through the lack of driver support for a while with Windows 2000 Professional. The OS itself was pretty solid. The fact that Windows 7 and 8 are mostly vista at their core is testament to that.
Works for me. Oh, you're running Linux? :)
Meanwhile, USB works just fine on my Mac, Windows and FreeBSD hardware. Sounds like someone implemented the spec and someone is blaming everyone else.
Given that the spec says this is a MINIMUM value, then I'd say the misinterpretation is in Linux - by hard-coding in 10ms and attempting to use devices after that. As per TFA, an interrupt is generated by an xHCI controller when the device is ready to use again. So, blindly attempting to use the device again after 10ms is breakage in LINUX.
I'd also say that the USB spec is written in a pretty broken way to cause said confusion, but that's a whole new issue.
I suspect they wont immediately. More likely they will cut costs and instead of having 4 or 8 cores on your CPU, you'll have ONE, just clocked higher. a single core is a LOT less complex to program for, and it will run fast enough that it doesn't matter for some time. ditto for GPUs. I suspect you'll see the designs simplified, consuming less power, etc long before we see similar complexity designs to today on graphene.
A major reason is that the software just isn't there yet.
Maybe, maybe not. Intel have been hinting that they won't be using silicon for much longer, a couple of years back they said there was maybe 3-4 generations of CPU left that they were going to do in silicon and that they had something "Really cool" in the lab to replace it with.
And I've got windows VMs that haven't had a reboot in over 6 months as well. What's your point? The only need to take the machine down is for scheduled updates that can't be mitigated by other measures in the meantime. Given the vast majority of issues appear to be browser problems or GUI issues when logged into the machine (and my servers are pretty much never logged into) then I can quite happily not run windows update every patch tuesday and still remain safe.
so that makes them the good guys now?
Correlation != causation. I agree most existing graphical programming environments are shit. But I don't believe it is a result of them being written in a graphical editor inherently. It's a case of getting that environment right being a hard nut to crack. Given that you can represent pretty much any program via flow diagram, the info is all there. It's just a case of someone writing a re-usable component library properly.
Also, there's an old saying in computer science: computing time is cheap. programmer time is expensive. Unless you are dealing with problems that NEED massively powerful CPU because every cycle counts, you're better off writing stuff in a higher level language to make it easier on the programmer and throw CPU/RAM at the problem. If your high level program gets the job done in an acceptable time frame, there's ZERO point in writing it in a more error prone low level language. If it DOESN'T run in an acceptable time frame, the 90:10 rule means you spend your effort optimizing the 10% of the code where the hotspot is and leave the rest high level.
I'd say the cause of programs getting slower and buggier is due to the inadequate teaching and the pressure from the accounting department - nothing to do with the choice of language really.
Oh don't get me wrong, I totally agree. We have a plague of access databases here that engineers have written that have become mission critical.
My point is that this is a symptom of there being a lack of a decent alternative - and before someone mentions SQL again, this is not an equivalent product. Sure they're both database engines, but what sets access apart is the ease of building a UI and glue logic around the database.
MS/other need to replicate that sort of functionality before a heap of people will dump access.
And in between the coding and the spec is the analysis which fleshes out the data and logic flow. Typically visually. Which is as hard as programming needs to be with an appropriate object library.
Exactly. And given that an entire program's flow, data inputs/outputs/etc can be captured in a flow diagram, this is about as hard as programming NEEDS to be for most apps that can re-use high level component objects. Which is pretty much most applications people want to use to get jobs done.
Not really. Pretty much all your glue logic in a typical program to tie the blocks together could be done visually. There's nothing magical about programming in a high level language that necessarily requires the vast majority of it to be done in a text editor.
Sooner or later programming is going to go this way and to be honest, the sooner the better. The computer is meant to make life easier on its users to get a sequence of steps done. All learning a specific textual language does is place a barrier to entry in the way of the user.
Yes there are specific niches where you'll need to go into low level code, but most of the apps people want to use to get stuff done aren't like that.
Yup. Far too many people miss this point.
This is all any programming library use is. If you write in C, C++, Java, etc. this is mostly what you are doing also.
I think this is is an indication that MS (or someone else) should fill the huge hole in the market for a product LIKE Access to use, which isn't crap. SQL server is not the same thing, and it is nowhere near as easy to prototype a database driven application in SQL as it is in Access.
The fact that many people (including myself) use access from time to time to quickly solve problems in an hour or so (my most recent use was a decoder database for Windows IAS logs) that would take far longer than that to even create the back end tables and relationships in SQL DESPITE the suckage should be a massive hint for someone to put out an equivalent that DOESN'T suck.
So because you saw some old app fuck over a client who is too stupid to back up, your servicing experience with your car was less than spectacular?
If software does the job with a minimum of fuss, it is fit for purpose. Re-implementing the wheel "just because" is a waste of time, resources and will increase the cost of your servicing to pay for it.
Citation needed. Is this why they were caught deliberately misusing the Safari "do not track" request?
Yeah, fuck those guys who want to be able to sort their directory listings when prefixing files with datestamps, right?
Uh... Windows update was automatically updating systems back in 1995.
Have they changed the brain damaged behaviour whereby it re-attempts to connect once every 5 seconds if unsuccessful yet?
Its double the cost of x86 hardware in terms of RAM and CPU. CPU is generally abundant; you already have multiple hosts in your cluster anyway. You can limit it to VMs that really need to be up, only.