Slashdot Mirror


User: smash

smash's activity in the archive.

Stories
0
Comments
7,084
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 7,084

  1. Re: For / While in C on Ask Slashdot: What's the Most Often-Run Piece of Code -- Ever? · · Score: 1

    Yeah i didn't mean to imply that pixar uses GPU rendering. Merely that when i was thinking about the most executed code in existance, it would be to do with rendering in some way. But GPU rendering in desktop machines worldwide probably trumps ray tracing on CPUs (or whatever) in the movie industry due to sheer number of users.

  2. Re: For / While in C on Ask Slashdot: What's the Most Often-Run Piece of Code -- Ever? · · Score: 1

    Yup. Modern GPUs run at high clock rates, and regularly at 100% load for long periods of time, doing relatively simple, repetitive processes.

    I was going to suggest perhaps some ray-tracing code used by say, Pixar, but the army of modern GPUs in regular gaming machines probably tops that.

  3. or not on Chrome Is the New C Runtime · · Score: 3, Insightful

    Lets talk about this again in 12 months. Given the NSA bullshit, Chrome, Apple and Microsoft all being involved, I'm not sure people are going to be keen on yet another layer of abstraction for surveillance to be hidden in.

  4. Re:Everytime I posted about this sort of problem on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    Yet, I can actually copy files from disk to disk on Windows or my Mac without the responsiveness of say, trying to start an app at the same time from one of the disks going to shit. Linux needs an IO scheduler that doesn't either suck or require fucking around to make it responsive to user interaction under load.

    Running both Windows and Linux on this machine (Core i5-4430) and as far as disk IO goes, Windows blows the doors off Linux on it, in terms of responsiveness when copying files. Can it be tweaked? Maybe. Why should I have to fuck with it?

  5. Re:Let me get this straight... on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    Firefox is still a piece of shit. I gave it 3 months until about 3-4 weeks ago (after a long hiatus because of non-resposive UI issues) and guess what? It still sucks. Don't care how much RAM it uses. Don't care how many plug ins it has. One browser tab makes the entire thing non-responsive. Chrome fixed that issue what... 6+ years ago now with process per tab?

    And yes, IE since version 9 is actually half decent. Guess what? Also multiple process.

  6. Re:Over a decade on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    150 bucks for a new OS every 5-10 years is hardly "big bucks".

  7. Re: Over a decade on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    Erm. Youtube, on Linux. Or my Mac. Still gives me ads to fix windows malware.

  8. Re:Over a decade on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    Pretty much. For all the shit apple cops about form over function, the OS X desktop actually fucking works. Including scripting of shit that normal people can use.

  9. Re:CORRECTION on Microsoft Quietly Fixes Windows XP Resource Hog Problem · · Score: 1

    Erm. Windows 2008 R2 is a far better server than Windows 2003 ever was.

  10. Re:Hottest in 100 years = cooling down on Heat Waves In Australia Are Getting More Frequent, and Hotter · · Score: 1

    Wrong. We have records going back to the late 1800s.

  11. Re:Hottest in 100 years = cooling down on Heat Waves In Australia Are Getting More Frequent, and Hotter · · Score: 1

    Exactly. We do actually have hotter weather on record within the window that we have been keeping records here.

  12. Re:Hottest in 100 years = cooling down on Heat Waves In Australia Are Getting More Frequent, and Hotter · · Score: 1

    No - i live here in Western Australia, and our records go back to the 1890s or earlier. So yes, 100 years ago, some years after records began, we had hotter nights for example (was in the news that we had the hottest night in 100 years here in perth last week, for example). I'm not saying climate change is or is not real, merely refuting the statement that we recently had the hottest weather on record.

  13. Re:"Intel Dev" in Headline is misleading on Intel Dev: GTK's Biggest Problem, and What Qt Does Better · · Score: 1

    Sure, there are idiots in some companies. However, there's a lot more who are unemployed. Given the current economic situation (where companies are laying off the dead wood), and it is in his field of interest, I'd suggest that mentioning that he works for intel is relevant.

  14. Re:"Intel Dev" in Headline is misleading on Intel Dev: GTK's Biggest Problem, and What Qt Does Better · · Score: 3, Insightful

    Well, it does give some background that he is actually deemed to be employable by intel, rather than some hack pumping out shit in his bedroom.

  15. Re:QT Devs on Intel Dev: GTK's Biggest Problem, and What Qt Does Better · · Score: 3, Informative

    More diplomatically put: Qt was originally a for money project aimed at cross-platform application development. GTK is a toolkit that started out being branched off from one single application and is now developed by a bunch of people for Gnome, with little focus on actual application development, or any other platform other than Linux. Even other Unix platforms get shafted by Gnome.

  16. Re:So does this mean the TrueCrypt hijacking busin on TrueCrypt Master Key Extraction and Volume Identification · · Score: 1

    And like a physical key-ring, no one else has developed a better solution that actually works in the real world.

  17. Re:When upgrades break code on Why Do Projects Continue To Support Old Python Releases? · · Score: 1

    All that does is delay acceptance of the new version and doesn't make it any easier to migrate. It just kicks the can down the road a little bit.

    If the creators of C made so many code-breaking changes to C over the years, there's no way in hell it would be the language of choice for operating system development. Every time you make a change to the language which breaks code because you can't be bothered maintaining backwards compatibility, you are breaking the code for all of your users and creating a shit-tonne of extra work (and wasted time) that otherwise would not exist. There really should be a fucking good reason for that.

  18. Re:People don't upgrade on Why Do Projects Continue To Support Old Python Releases? · · Score: 1

    IN the real world, a lot of the code that gets written is not by developers, but by others to cater to a niche requirement. That becomes entrenched.

  19. Re:People don't upgrade on Why Do Projects Continue To Support Old Python Releases? · · Score: 1

    No. It's about the company that pays them not wanting to pay for development time/resources to track new versions of whatever. Easier/harder doesn't come into it, it is a simple case of X hrs of developer time at $Y/hr required - No, we do not want to spend.

  20. Re:People don't upgrade on Why Do Projects Continue To Support Old Python Releases? · · Score: 1

    So they're still supporting Kernel 2.2 as well then, yeah?

  21. Re:Many eyes... on 23-Year-Old X11 Server Security Vulnerability Discovered · · Score: 1

    So basically you are saying that if you expend a minimal amount of effort to secure a Windows environment, you can secure it. Yet if you have to spend some time to secure Linux (which has had this vulnerability for longer than the OS has existed), that's OK.

  22. Re:Wrong question on Why Do Projects Continue To Support Old Python Releases? · · Score: 1

    This is why you write shims.

  23. Re:People don't upgrade on Why Do Projects Continue To Support Old Python Releases? · · Score: 2

    Its not about making developer's lives easier. It is about not pissing money into the wind merely to maintain the status-quo. You think developer time is free? Even if it is un-paid, developer time wasted on re-writing working code is time that could be spent writing code to solve new problems instead. I.e., there is an opportunity cost.

  24. Re:People don't upgrade on Why Do Projects Continue To Support Old Python Releases? · · Score: 4, Insightful

    The only exceptions are systems designed with the mainframe mindset that you code it and forget it for 3-4 decades

    You just described any serious application used in production in a real business, who's core industry is not "software development". Fucking around re-writing stuff costs money. Re-testing everything costs money. Fixing bugs costs money. Unless there's a REALLY good, real world fucking reason to be spending said money that will directly impact the business in question it is wasted money.

    This is exactly the sort of thing many open source people don't seem to get: even if your software/development tools are FREE, pulling major compatibility-breaking changes costs real world people real world money. THIS is why Windows is so popular in the real world.

    We know the security is inferior. We know the stability is often questionable. We know it costs money in purchase and/or ongoing licensing fees. BUT: you pretty much get a guarantee that any code written today will continue to run for at least 10 years (due to specific OS version support for that long) and likely a lot longer than that; due to API support normally extending even further. Re-writing shit just because the platform changed costs real world time and money.

  25. Re:When upgrades break code on Why Do Projects Continue To Support Old Python Releases? · · Score: 5, Insightful

    Exactly that. Nobody cares if your new version is 10% faster, or has new feature X. If someone is using your language for something serious in the real world, and your upgrade BREAKS CODE, then all bets are off.

    Even if the time and effort (in the real world, money, essentially) is spent to "fix" the project to work with the new version, all prior testing is essentially worthless, and the developer can't "trust" the code is correct and bug free any more until they've had sufficient time and testing to be comfortable with it.

    This problem is endemic in open source unfortunately, and not just for developers - constant UI change, application deprecation/replacement, etc. Every time you change something significantly, there's a real cost to any person using it, even if your software is free. Even if they decide not to use it any more - they need to find a replacement and re-learn how to use the replacement.

    I'm not saying "never change anything". But more work needs to be put into shims, switches, etc. to enable backwards compatible behaviour if possible - even if it is not enabled by default.