Slashdot Mirror


User: Tatsh

Tatsh's activity in the archive.

Stories
0
Comments
488
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 488

  1. Re:The horror! on Slashdot Launches Re-Design · · Score: 1

    That's because Firefox sucks, and too bad.

    You must have a GeForce 8000/9000 series (or one of the ones affected). That's where Gtk+ and Nvidia's driver just doesn't work well at all when it comes to Firefox scrolling.

    Nvidia doesn't care. Mozilla seems unable to fix their memory leak problems as well, as with each Firefox 3.6.x we keep hearing the same old thing: more memleak fixes.

    Switch to Chrome (or chromium). It has none of these problems.

  2. This is fine; close to native DS virtulisation?! on OLPC Set To Dump x86 For Arm Chips In XO 2 · · Score: 1

    I do not think Microsoft will work on an ARM port, even something that translates x86 to ARM because the ARM processor is likely to be way too slow for this.

    Nintendo DS runs on an ARM architecture. Maybe now we can run those games at full speed on another device? Certainly now with an emulator on this device there would be less translation and more instruction passing. Great!

    Same goes for any other ARM-based processor device and emulation.

    Wine will not run on this and neither will Windows. I am so fine with that.

  3. Re:DNAS Error -103 on Emulation Explosion On the PS3 Via Linux · · Score: 1

    Yeah, I am so pissed Amplitude went down. Who wants to start a server implementation project?

  4. Re:No on Emulation Explosion On the PS3 Via Linux · · Score: 1

    Very true. Microsoft has made programming for 360 nothing too new, which can be good and bad.

    For PS3, you get SPE's and PPU's (6 SPE's) to handle threads (sort of like cores). It can be automatic, but it is better if you optimise your code for each SPE. This extra work does not look like it is being done. Games on PS3 vs Xbox 360 are looking pretty much EXACTLY the same or WORSE. Sony made PS2 hard to work with at first as well. New technology (like the Cell processor or the Emotion Engine (MIPS-based)) is good, but developers need to just say 'no' to making PS3 games if they are not going to take advantage of the system. But hey that's why Sony has its 3rd party developers who will do PS* only right? Actually, they are all almost gone now, including Rockstar (who used to make GTA only for PS* and PC).

    On Xbox 360 you have 3 cores and I bet most developers rely upon the library to choose which thread goes to which core. Easier.

  5. Re:No on Emulation Explosion On the PS3 Via Linux · · Score: 1

    Ever buy a Chiquita banana? A GE lightbulb? Hugo Boss shirt?

    No Hugo Boss shirt. Abercrombie however...lol

  6. Re:No on Emulation Explosion On the PS3 Via Linux · · Score: 1

    Agreed. They are working hard with the US government (instead of fixing the problems themselves) to fight piracy, preventing things like the M3 or R4 products.

  7. Re:No on Emulation Explosion On the PS3 Via Linux · · Score: 1

    You missed my point completely. If I wanted to right now, and had the funding, I could make a game 'for PS3' and give instructions on how to use it. Perhaps, 'you need Linux installed, and you need to do blah blah with the disc'. But guess what. I would not be licensed to do that (Sony would probably sue), and even if I had the money to take on the risk, it would never be worth it because of the limitations put on Linux for PS3.

    Linux for PS2 and Linux for PS3 are just Sony's feeble attempts at saying 'We support open source'.

  8. Re:No on Emulation Explosion On the PS3 Via Linux · · Score: 4, Insightful

    The one thing I hate about console-proponents is that they exist. Each console has its pros and cons. Just because you bought a PS3 instead of an Xbox 360 or Wii does not make you better than someone else. AFAIK, nobody is paying you to advertise for Sony either.

  9. Re:Wow, Guess That Makes The 360 A Massive Failure on Emulation Explosion On the PS3 Via Linux · · Score: 0, Troll

    Screw people who post anonymously.

  10. No on Emulation Explosion On the PS3 Via Linux · · Score: 4, Informative

    1. First of all, there are more options for PS3 then YD including Gentoo, Ubuntu, Fedora, and others.

    2. Access (due to Sony scared of people making good games for PS3 Linux for 'free') to the RSX (graphics card) is very restricted. A few firmware revisions ago it was accessible but of course that gets fixed. And without the latest firmware, you cannot play certain games.

    The PS3 is a flop anyway. If you want to emulate these mentioned systems, you are way better off with a PC, Xbox 1, or Wii.

  11. Lazy web developers on Microsoft.com Makes IE8 Incompatibility List · · Score: 0, Troll

    Sure Microsoft.com makes the list. The developers of the site are lazy. All they care about is that it 'works' with IE and Firefox and a few other browsers. They do NOT care one bit about W3C compliance. Do you think they put the site through the validator? I DOUBT it. Otherwise, they'd fix the 176 errors .

    And then there are web developers for big companies that do the same thing. Amazon.com: 1580 errors, eBay: 226 errors and a big one for a lot of us on Slashdot I am sure (US based people), Newegg.com: 566 errors. What is so hard about validating to the standards in place? If you do it from the start, you have no problems. But developers of these sites clearly do NOT care as long as the site 'loads'.

    Do not forget so many of these sites rely upon Microsoft's ASP.NET, ASP and/or IIS.

  12. Re:IE must be architecturally borked on MS To Slip IE8 Into Vista and XP Through OEMs · · Score: 1

    Are you guys surprised by this news? Of COURSE they are going to put IE 8 into XP and Vista now that it is nearing completion what with RC's out now. I do not really care as I slipstream it anyway (with nLite), but otherwise I ignore it and use Firefox or Opera.

  13. Re:Secure? Sure. on Kaspersky Customer Database Exposed · · Score: 1

    using namespace std;

    eh? :P

  14. Re:Secure? Sure. on Kaspersky Customer Database Exposed · · Score: 1

    Object-oriented programming is difficult to use and doesn't increase productivity.

    arguable but I will agree that in C vs C++ I choose C

  15. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    Very true. Both C and C++ standards are not perfect on all platforms. Mostly we can expect them to work exactly the way we want on x86 and PPC and that's about it. ARM, MIPS, etc; on those we just hope it works.

  16. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    The Mono team should be working hand-in-hand with the Wine team if they truly want to make cross platform apps a reality, anything less is just a half-hearted attempt to benefit Microsoft's technology.

    Agreed. And you have to remember that WinForms (the Windows-look-alike GUI part of .NET) is still not fully supported. To me it looks like there is little effort being spent on this. Why? Because there is Gtk# because [sarcasm]THAT will solve all our problems[/sarcasm].

  17. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    Maybe the .NET or Mono framework should never be used for front-ends to CLI programs on any platform, but there are many on Windows. At the moment, any Windows user might assume that a .NET app will 'just work' on Mono not knowing that it is just front-end to a Windows app.

    The Mono team has no plans to support launching any type of binaries other than Mono and .NET ones. They will not work with the Wine team, which is clearly shown by how crappy .NET AND Mono run on Wine.

    I am on the side that finds Mono a waste of effort based upon the way it has gone.

  18. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    1. Algorithmic improvements will always trump optimizing execution speed.

    And what are these magical algorithms that only work in Java and C# but don't work in C/C++?

    2. Unless there is a hard requirement, development time is more important than raw performance.

    I fail to see how Java and C# reduce development time.

    3. Hardware is cheaper than developers.

    You have clearly never done any embedded work. You think a customer is going to want to pay the extra money for a device that runs Java instead of one that does the same thing and runs on a $1 micro running C/C++? Furthermore if you seel 100,000 pieces, every $1 of hardware is $100,000.

    4. A rich and flexible library is more useful and stable than custom coding for performance.

    Depends on the application. Write a CAD tool in Java and see if customers don't mind it when their compilations take an extra hour to finish

    My point exactly. And another thing, as expressed in your last point, time is expensive! What is more important? Getting software out the door faster that sucks? Or getting your designs ready (on time, on schedule) with a native app that will not rely upon the (buggy) Java VM or .NET.

  19. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    So it is a money issue. That is the saddest part. We are going to have lesser performing applications all because software companies want to pay less to developers.

    I would rather pay $100 more for a sleek native program vs a Java one.

  20. Re:The thing is... on The Case For Supporting and Using Mono · · Score: 1

    I used Mono pretty recently and was completely disappointed by lack of features in comparison to .NET. I thought it was supposed to be the open source equivalent, yet it is versions behind and lacking so many features.

    At the same time, Wine needs .NET too. Mono has no plans of having Wine or SOMETHING run native apps (Windows exes) that a C#-based front-end to a CLI app might use. This is my other problem with .NET. It is seriously locked to Windows because Windows gets all the features, and gets to run the native apps too.

    Okay, so you can code less with C# and possibly Java. So what! Your code is still going to run slower than C code. I know about Paint.NET; seems to be just an example application supporting the usage of .NET, nothing more.

  21. Re:for quick, cross-platform development c/c++ suc on The Case For Supporting and Using Mono · · Score: 1

    I'll agree with you that C++ sucks. OpenMP is looking good though. Right now I use pthreads-w32 for Windows and POSIX threads elsewhere (Linux, BSD, OS X).

    It is true that programming for platforms is sort of an issue with a bunch of #idefs but I find #ifdefs to be a lot better than starting from scratch.

    With something like Qt (speaking of the GUI toolkit and ONLY that), you will have very few #ifdefs in my opinion because MOST of the code is completely cross-platform.

  22. Re:What's the point with Qt now fully free? on The Case For Supporting and Using Mono · · Score: 1

    Agreed. The Qt API is RIDICULOUSLY easy to use, especially in comparison to Win32 API and even GTK+ and wxWidgets.

    Death to Mono!

  23. Re:There isn't one. on The Case For Supporting and Using Mono · · Score: -1, Troll

    Next question?

    de Icaza can go to Hell along with his bosses at Microsoft.

    Agree. de Icaza is a Microsoft-paid Microsoft technology-supporting money man.

    But you go work for Microsoft today as a 'Linux enthusiast' and you will be lying to death tomorrow with all that money you got.

    Where do you want to go today?

  24. Re:Qt on The Case For Supporting and Using Mono · · Score: 1

    s/using Java or Qt/using Java over Qt/g

  25. Re:Qt on The Case For Supporting and Using Mono · · Score: 2, Informative

    Lucky for Windows users, Windows will always search the current directory first for DLLs that an app needs. So just include them. QtCore4.dll and a few others. Many apps ship their own version of Microsoft's DLLs just to make sure the app will call the correct version without worrying about a newer version being in system32 or the wrong version being called from WinSxS.

    No, there is no case for using Java or Qt now. Qt looks sleek on every OS and is SO incredibly easy to program. It is native and is very fast.