Slashdot Mirror


User: FrostedChaos

FrostedChaos's activity in the archive.

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

Comments · 406

  1. Re:The momentum is pushing him away... on Stallman Pushes For Free BIOS · · Score: 3, Insightful

    Actually, I think I am pretty safe from this glorified copy protection bullshit.

    We broke it back in the 80s when it first came out... we're breaking it now, and we'll break it in the future.

    This kind of specification could only work if all hardware conformed to it... which will never happen, for a lot of good reasons. First of all, there is a lot of perfectly good legacy hardware floating around, that has no "copy protection" functionality whatsoever. For example, I have a microphone jack and an old PC. That is enough to allow me to make sound recordings of anything, DRM protected or not.

    Secondly... there are plenty of foreign companies that will supply the necessary hardware for breaking this crap, if it comes to that. For example, I really doubt communist china will try to prevent people from developing and selling hacked DRM BIOS chips, etc. In fact, they may even encourage this sort of thing. They have little interest in being economically enslaved to "content producing" nations like the U.S.

    Don't forget, a lot of semiconductor fabs are located overseas, to avoid harsh environmental regulations here in the U.S. Well, guess what... U.S. law does not apply there.

    Even if there weren't foreign havens for piracy, there would always be clever individuals able and willing to break the system. Like illegal drugs, information will always be available to those willing to spend the time and effort-- and maybe the money-- to find them.

    I'm more afraid of boneheaded lawas that restrict fair use... like the DMCA. I've never seen a copy protection scheme that I couldn't break, given the time. I have seen a lot of court cases that I couldn't win, and I have no wish to be involved in one.

  2. Re:Good start? Why was RH not? on Is Dell Just Testing the Market? · · Score: 1

    Linux is essentially architected the same way a modern mainframe O/S are architected. You have a reasonable user interface that is connected to a terrible one via pushrods. All the work gets done by the cruft underneath, which does not matter much most of the time, but when something goes wrong you have to start fiddling with the engine.

    Heh... car metaphors. If this were a different forum, you might very well start an OS flamewar.

    I guess the truth is, to a certain extent, linux does have a terrible interface. The console stuff isn't really all that bad, although it's a different metaphor than most Windows users are used to. No, I think the main problem is really X-Windows.

    You might expect X to provide some kind of rudimentary desktop manager functionality. Some kind of file browser? A start menu? Hell, even a button labelled "help?" Nope, that is left up to "third parties" like FVWM, MWM, and KDE. As a consequence, there is really no standard way of doing *anything* on the linux desktop.

    Now, I know some people will say, who cares? You can install a desktop manager if you want. But, of course, the truth is, that's not the same thing. GNOME and KDE are not built in to X-Windows the same way microsoft's GUI is built into its OS.
    For one thing, it introduces a needless layer of abstraction, which adds bugs and performance problems. For another thing, it's not standard. That means it's going to be more difficult to get help when you need to do something.

    For example, let's say I want to edit my /etc/fstab, using some kind of GUI system. Now, I could go online and fetch a 3rd party program to edit this file. Why 3rd party? Because, unlike Windows, linux comes with no standard software to do this task. Now, once I have the GUI program, I will need to learn how to use it... which takes time and effort. Most likely, I can't ask my friends, because they will probably be using different tools. There is no *standard* way.

    Except, of course, editing the file with a text editor, which is what everyone in the linux scene eventually learns to do. It is much easier than navigating the non-standard GUI tools.

    Now that we've established just how little X-windows actually provides (besides a frame buffer and a client-server system for drawing windows on the screen), let's talk code quality.

    Like the Matrix, you cannot understand how truly crappy the x-windows API is until you have experienced it. I have had this privilege (?), since I was hired to improve performance of an xwin app.

    First of all, X provides only the most minimal functionality imaginable. There is no native support for dialog boxes, scroll bars, or buttons, or... really anything. Naturally, this makes for massive inefficiency, as people scramble over themselves to re-invent the wheel. A lot of toolkits have sprung up to fill the void. Of course, this is just another unecessary layer of abstraction for bugs and inefficiency to hide in.
    Considering that we are also using a non-standard "windows manager" (like sawfish) and probably a "desktop manager" (like gnome), we have at least 4 different APIs involved for the simple task of drawing a window on the screen.

    This is not good, folks. Even the non-programmers among you should smell this by now.

    Even a simple "hello-world" application written in X-Windows takes 3 pages of code. The horror, the horror. To actually do anything useful with it, directly, is a nightmare. Imagine function calls that take five or six pointers to structs. Imagine a system created by people who had no concept of "user interface." Imagine a *giant* C program written by mediocre programmers from academia, with little or no attention given to refactoring.

    That's X-Windows.

    This may offend some people here, but I believe that even the win32 API is better than this MIT-spawned horror. If ever the open source community could get together the resources to replace this altar to satan, it would doubtless improve people's per

  3. Re:Playing God, with hilarious results. on Simpsons Fan Creates Real Tomacco Plant · · Score: 1
    Pascal's wager doesn't work, because different religions tell you to do different, and often directly contradictory things. You can "burn in hell" for being a heretic, just as easily as you can for being a nonbeliever.


    Perhaps you should be worshipping the grand poobah of Crapholistan-- after all, there is about as much evidence for that point of view as there is for any other religious view.


    IMHO, religions are just mental parasites anyway. No legitimate idea would propagate like a disease, or try to tempt people with pyramid-scam-like rewards.

  4. Re:What is D? on The D Language Progresses · · Score: 1
    How can you seriously write a program and call what you release professional if it pauses unpredictably for indeterminate amounts of time every so often?
    I never said garbage collection had to be done in the same thread as everything else. It's true, threads are difficult to implement in C, but there are other languages out there.


    If those problems are slowing (or will slow) a particular project down, then C may not be the right choice.
    The problem is that these flaws don't slow most projects down, and they continue on to create a crappy final result. There's no reason why most open-source development shouldn't be done in a fault-tolerant and high-level language. Period.


    But instead, we have thousands of lines of hackish and brittle C code, and a macho attitude that higher-level languages like Java and Lisp are for sissies. Yawn.

  5. Re:What is D? on The D Language Progresses · · Score: 1
    Perl isn't a real language. And the incompatibilities, security problems, and memory leaks seen in many programs are a direct consequence of the many flaws in C.

  6. Re:Already slashdotted on Number of Jobs by Programming Language · · Score: 1
    Ewwww..... why would anyone use Perl? There's always a better choice.


    Scripting can be done better in python or bash. Simple applications can be done better in Java. Large programming projects can use C, or C++.


    Seriously, why would anyone ever write Perl? I guess it gives you more job security. Because once you write anything more than 100 lines in Perl, you can forget about anyone else maintaining your code!

  7. Re:wonder what this means on Microsoft Next Generation Shell · · Score: 0
    REALITY CHECK. You can buy a 700 MHz desktop machine from Wal-Mart for $200. If you choose to live in the past, why should the rest of us cater to your needs?


    Optimization is expensive. It takes programmer time ( = money). Worse yet, optimized programs will almost always be harder to maintain, and buggier. There are all sorts of hidden costs that come in. How do you measure the cost of a dozen segfaults a week? I don't know, but it's pretty steep!


    In the future, maintainability, portability, and ease of development will be more important than performance. Hardware will make up for the deficiencies of programmers.


    I know it's sad, but the days of Mel are over.

    : (

  8. Re:Uggghhh on Is Red Hat the Microsoft of Linux? · · Score: 2, Insightful
    What would possibly make you think they are "setting something up for the future"? Do you think that they would abandon the strategy that has brought them so far, and which is their main business plan?


    The whole point of open source is to provide people with open standards that don't lock them into a particular vendor. Why would you think that would change in 10-15 years? The code that is GPL'ed now will still be GPL'ed then.


    Seems to me the last thing anyone needs to worry about is stupid crap like this. Get some facts behind your argument, and then come back with your labels.

  9. Re:department of redundancy department on Gamers Drive High-End PC Market · · Score: 1
    Um, buggy kernel modules can most certainly cause a linux system to hang, and worse. And yes, I've seen it happen. Also, some applications with superuser privileges can do the same. Where have you been?

  10. Re:Safeguarding Secrets 101 on Network Hacking · · Score: 1
    Actually social engineering attacks would probably be more likely to work in a large company, where people don't know each other.

  11. Re:Not exactly a suprise on All We Want Is Whatever's On Your Machine · · Score: 1
    Now that the distribution networks they own are obsolete and unecessary, maybe the RIAA should just go away...

  12. Re:Mod Parent down on Bootable Linux Demo Distro - Knoppix · · Score: 1
    Who said he was interested in ACL? For all you know, he might be the only user on his computer.

    It's quite common these days, you know. They call them "Personal Computers."

    As for whether FAT or NTFS is easier to fix, I have no idea. I use Debian, myself. But I can see why the parent poster might want to use FAT (which has been around a lot longer, and might have more tools available to fix it.) Remember that this is not linux, and new software for him to use might cost money.

  13. Re:Legitimate reasons for changing the IMEI? on Hack Your Phone, Go to Jail · · Score: 1

    Actually the average does not need to be the median.

  14. Re:Of course backwards-compatible on AMD's 64-Bit Chip · · Score: 1
    To claim, as you seem to be doing, that clean room designs are invariably worse is ridiculous.

    The branch delay slot in MIPS was a bad idea, from today's perspective, but so was the stack-based FPU in x86. Crusoe was never designed to go "toe to toe" with x86 processors. It was always intended to fill the low-power segment of the market. Unfortunately, Intel simply underclocked its old processors, put them on a newer process technology, and let materials science do the rest. (Another problem is that in laptops, the TFT screen is often the main battery drain.) As for Itanium, I haven't really studied it, so I can't say what its strengths and weaknesses are.

    I notice you didn't mention the other successful clean room designs to hit the shelves this past decade. Like the powerPC processor, which still beat x86 designs, megahertz for megahertz. Or the POWER processor developed by IBM, used in high-end servers. Or the Alpha, still the standard of excellence in scientific computing, despite being bought out. A lot of the engineers who designed the Alpha worked on the Athlon as well. I guess they just couldn't get enough "garbage."

  15. Re:Mod Parent down on AMD's 64-Bit Chip · · Score: 1, Informative
    Unfortunately, AMD chips do tend to be less reliable than Intel chips, for several reasons:

    1) Lack of a thermal diode. The CPU will burn up easily if the heat sink falls off, even partially.

    2) Cheaper packaging (this has to do with the construction of the cpu)

    3) Cheaper motherboards. A bad motherboard is a bad investment, no matter how low the cost is. Don't buy a Via.

    None of this should prevent people from buying AMD, but it is something to think about.

  16. I agree with this post on Perl 6 Synopsis 5 · · Score: 1

    I agree with this post!

  17. Re:More efficient code - not faster processors on Guide To Designing Low Power Handhelds · · Score: 1
    Hey, thanks for sticking up for me, Quinto.

    I interpreted the original poster's point to have been "hand-optimizing code is cost-effective, let's see more of it," and set about trying to refute that. If I had thought he had been referring to algorithmic improvements, I would have completely agreed with him.

    My argument was that hand optimization is actually bad in most cases. There's lots of good reasons to keep programmers innocent of hardware and OS details. Portability amd maintainability come to mind. Another thing to remember is that hand optimization actually makes coding complex algorithms more difficult.

    I don't think programmers should fear the coming of these new ideas. But they should realize that the days of sitting around, trying to squeeze a few bytes out of the inner loops, are over. In most cases, their time would be better spent on making the code more reliable, or finding better algorithms to do what they want.

    And don't even get me started about code reuse...

  18. Re:The IEEE has lots of brains... on IEEE Drops DMCA Reference in Authors Copyright Form · · Score: 1
    It worked better for the americans. Navajo is a pretty "obscure" language, wouldn't you say? And yet it worked a lot better than the codes used by the other sides. It was never "broken" during the war.

  19. Re:My speculation... on The Hard Business of Selling Hard Drive Platters · · Score: 1

    Um... what's wrong with pricewatch? I've ordered from there many times, never had a problem.

    Of course, I didn't order the absolute cheapest parts on sale (in most cases) because I knew they would be crap. I also didn't order speakers from there because I wanted to listen to my speakers before buying.

    So in conclusion, if you really feel like going to a retailer and paying 2x the OEM price, that's fine with me. But don't use it as an excuse to show off your superior "knowledge" because the rest of us will laugh at you. (And there's still no guarantee the salesmen won't rip you off. There is no substitute for knowing what you're doing.)

  20. Re:beat a-round the bush on Pet Bugs? · · Score: 1

    There is no finite decimal expression for 1/2 in base 9. Thus, you'd have to round first, not after.

  21. Re:what am I missing about vid cards? on Matrox Parhelia Benchmarks and Review · · Score: 1

    I can tell the difference between a 75 Hz display rate and a 60 Hz one, easily. I really prefer >100 Hz.

    60 Hertz, that's kind of like a strobe light... on most monitors.

  22. Re:More efficient code - not faster processors on Guide To Designing Low Power Handhelds · · Score: 2, Insightful

    Which do you think is more cost-effective for a software company?

    1) tell all their programmers to spend lots of time optimizing their code-- probably making it faster but harder to debug and maintain

    OR

    2) wait for AMD and Intel to cook up a new batch of microprocessors

    If you guessed #1, you just lost. Guess what? Assembly langauge programming was faster, but it died out because (software) optimization stopped being a priority. Already C is starting to look archaic (except maybe for systems-level programming).

    The reality is, software in the future will be buried under more and more layers of abstraction, just because it's easier that way. Easy to use, commercialized high level languages like Java are the future.

    P.S. Please no flames about compilers vs. human assembly language programmers. Most of the binaries you run are probably compiled for a 386 anyway, if you use linux.

  23. Re:Clinton-Gore transgressions on EU Ratifies Kyoto Treaty · · Score: 1

    Great idea! But here's another one...

    Your computer is not "100% safe" either. Connecting to the internet runs the risk of hackers taking control of your system... yes, it may be a small risk, but it is still there. So I think you should give up posting on slashdot, and sit in a cool, well-ventillated room (not in the basement, there's radon down there!) for the rest of your life. I would caution against interaction with other humans; they often carry diseases. They are certainly not 100% safe. Computers, of course, are also dangerous because they use electricity, and may contain materials like lead.

  24. Re:Mass Control on Appeals Court Finds "Nuremberg Files" Site Unlawful · · Score: 1

    Religion is not necessarily "forced," nor is "a form of mass control" a very good description of it. Religion is just like any other ideology: it's something people believe in that gives meaning to their lives. Communism was one ideology that gave meaning to the lives of millions. Nazism was another one. The hippy movement in the U.S. was yet another.

    The point is that ideologies are necessary to give meaning to people's lives. Without them, nothing is left, but decadence.

  25. Re:You think that's bad? on Microsoft Opts-In Hotmail Users · · Score: 1

    I don't think your analogy is a very good one: if there is ambiguity in what ASM a compiler will produce, that could be very bad. If there is ambiguity in what font is used on an HTML document... well, I really don't care that much. You're comparing apples and oranges.

    So is it better for "bad HTML" to cause an error message, or some semblance of what the correct document should be? I think the browser should give both-- similar to how iCab operates. Browsers are intended to be used by the general public, who are not necessarily programmers, and who most likely can't do anything about broken web pages they visit. Forcing bad HTML to display a blank document will only result in an unusable browser.