Slashdot Mirror


User: Skapare

Skapare's activity in the archive.

Stories
0
Comments
6,883
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 6,883

  1. Re:Field dependent requirement on Ask Slashdot: How Many of You Actually Use Math? · · Score: 1

    s/may/will/ ... that will fix it.

  2. Instead of calculus on Ask Slashdot: How Many of You Actually Use Math? · · Score: 2, Informative

    Calculus is virtually unused in computers. It was designed as a shorthand for a world that didn't have computers. What you need to be learning instead is Linear Algebra.

  3. Doesn't justify on Data-Fed Monitoring System Will Put New Yorkers Under Police Surveillance · · Score: 1

    Just because the private sector is doing wrong things, it doesn't justify the city doing wrong things.

  4. Re:Doesn't seem so bad on SUSE Slowly Shows UEFI Secure Boot Plan · · Score: 1

    Having Secure Boot enabled is NOT an issue, by itself. A badly designed Secure Boot is the issue. It needs to have a means to allow the OWNER of the machine to indicate which systems are to be allowed to boot, while still having the means to verify that those OSes have not been altered. Too many OEMs won't do this because the UEFI/SB standard does not require it.

  5. Re:Slashdot has gone batsh*t crazy on SUSE Slowly Shows UEFI Secure Boot Plan · · Score: 2

    1. UEFI Secure Boot is only required for Windows 8 Logo certification. It will not affect OEMs selling Linux machines, servers or hobbyist hardware.

    This IS THE PROBLEM. One should not have to go buy a different machine to run a different OS. Anyone who OWNS the machine should be able to install AND BOOT any OS they want. Your words are weasel words trying to make the problem look like it isn't there.

    2. Linux is now a multi-billion dollar market. Do you really think hardware makers are really going to stop supporting Linux? They'd basically lose all the major enterprises in the world over night.

    More stupid weasel words. The problem is not that they might stop selling hardware to be used for Linux. The problem is they won't be selling hardware that allows its OWNER to easily and securely change the OS (e.g. disabling UEFI is the wrong way to install another OS ... another OS should be allowed if the OWNER of the machine chooses to install it and authorize it to be booted ... including Windows 8.

    3. The Secure Boot specification requires that it can be disabled. This isn't just for open source nuts, it's also for Windows admins who want to downgrade an OS or run imaging software or run tests from a USB drive. If OEMs locked down the hardware so those tasks couldn't be completed they would go out of business.

    Disabling secure boot is WRONG! Stop being stupid. Everyone benefits from secure boot ... when it is done right. The RIGHT way to do this is to allow the OWNER, during BIOS setup, to add/delete ANY valid bootable OS to the list kept by the BIOS in flash memory that is completely shut off except when BIOS started from a hard reset or cold start. Chain of trust is not needed. Trust the OWNER. Period.

    If you think secure boot is going to take over and prevent people from running the software/OS they want, then you are being paranoid.

    YOU still misunderstand the problem. What is needed is for it to WORK ... CORRECTLY ... and provide secure booting for ALL OSes that the OWNER of the machine chooses to install/allow ... while making sure that no infiltration code under ANY OS can alter the owner's choice. YOUR description of secure boot FAILs to do that.

  6. Re:Slashdot has gone batsh*t crazy on SUSE Slowly Shows UEFI Secure Boot Plan · · Score: 1

    The scheme is poorly designed. THAT is all the reason in the world to fight it every way possible. That and say BS to Anonymous Coward posts. I bet you are one of those Microsoft people, too. The correct way to do this is for the "chain of trust" to be rooted at the owner of the computer, not some corporation, not YOUR employer, and not Anonymous Coward.

    The BIOS can do it this way. Start with a hardware feature that does not allow OS access to (write) BIOS code or data once BIOS "flips the switch" to turn it off as it makes the jump to start the OS is loaded. Encryption keys are not needed. All that is needed is for the BIOS to have an inventory of bootable partition hash codes. There will be a menu to add/delete bootable partitions. When one is added, the image to be booted will be scanned to generate a hash, and that hash is saved. When one is to be booted, it scans it again as it loads it, and looks for the hash in the list of valid bootable hashes. The partition number might also be compared, as well as the device ID for permanent devices. External media like DVDs and USB drives would still have the same test applied, and can have their loadable image hashes added, too (and they stay even if the media is removed and is used again later).

    The "chain of trust" is simply not needed.

    And stop linking to some legalese form. Link to the actual specs. Tell the lawyers to go pound sand. They are the ones that fuck up everything.

  7. The chain of trust is WRONG for this on SUSE Slowly Shows UEFI Secure Boot Plan · · Score: 1

    But it is the ROOT of the chain of trust that is wrong. Instead of some corporation being the root of trust, the owner of the computer should be that root of trust. A proper UEFI boot system needs to include an option in the BIOS to add ANY boot partition (such as the new OS you just installed) as trusted. That same menu should allow you to delete trust for any, as well. When you add trust, it scans the image to be loaded, calculates a checksum, and stores it into an area of Flash memory that can only be written to during the BIOS run from a hard reset or power cycle. Once BIOS runs an OS, that area of Flash is write protected, or maybe even completely out of addressable space so no OS can reflash (all of BIOS should be like this, of course).

    There is NO need for Microsoft or even the manufacturers to sign stuff. They are doing this WRONG. Of course, they chose to do this wrong so they would be in control.

  8. Simple solution, as always on Legitimate eBook Lending Community Closed After Copyright Complaints · · Score: 1

    Respond to each complaint, personally, with a lawsuit.

  9. Re:Deutsche Post's far ahead on Amazon Expanding Delivery Locker Service · · Score: 1

    Are they close enough to everyone that riding a bicycle can reach it within 10 minutes?

  10. Re:Privacy issues on The World's Greatest Competitive Programmer · · Score: 5, Funny

    Maybe not secure, but they developed the site in 21.3 seconds.

  11. Re:Sprint vs. marathon. You need them both. on The World's Greatest Competitive Programmer · · Score: 1

    I don't think they do programming contests for large scale projects that need to be reliable, accurate, and thoroughly secure ... such as a banking system. I would not put a whole lot of value in contest wins when hiring developers for such projects.

  12. Re:Nakedcams! on DARPA Creates 0.85 THz Solid State Receiver · · Score: 2

    Instead of buying X-ray glasses back in those days, I made my own. I got some plastic with a ribbed surface on one side, and placed two sheets with flat sides back to back. I cut them to fit some empty glasses frames. I had a few of my friends actually fooled that the double-imaging effect seen through them were parts of people's bones inside.

  13. Re:Is this just for communications? on DARPA Creates 0.85 THz Solid State Receiver · · Score: 1

    Which is why I didn't jump to the assumption it could just be used for digital purposes immediately. But, nicely linear analog is hard to do. There may be non-linear leftovers in the research.

  14. Re:Is this just for communications? on DARPA Creates 0.85 THz Solid State Receiver · · Score: 1

    I'm not expecting some CPU at the capacity level of an x86 or even ARM chip. Something smaller would make sense. Very basic instruction set, few registers, no floating point, just something to provide logic control that can make decisions at rates above what today's host computers can barely get a clock pulse at. Maybe at best an 8-bit architecture, if even that.

  15. Re:Is this just for communications? on DARPA Creates 0.85 THz Solid State Receiver · · Score: 0

    That could also be used for transmission purposes.

  16. Re:typo on DARPA Creates 0.85 THz Solid State Receiver · · Score: 4, Funny

    This is Slashdot, not Wikipedia.

  17. Is this just for communications? on DARPA Creates 0.85 THz Solid State Receiver · · Score: -1, Offtopic

    ... or are they going to try to make a CPU/GPU core at this speed?

  18. What I hate most about eating insects is ... on Meat the Food of the Future · · Score: 1

    ... the skin and even some legs getting stuck between my teeth. If they would just butcher this mini-livestock to remove these parts, I'd go for it. And also remove the stinger from scorpions.

  19. Software needs to grow up on Bedrock Linux Combines Benefits of Other Linux Distros · · Score: 1

    ... and learn how to install and run on all the major Linux distributions. Don't worry about the weird ones. But the ones that are based on a major one generally should also work.

    Software does not necessarily have to come packaged in the same packaging system if it is not something other software might depend on. So I'm not talking about libraries here. Games are mostly going to fit in this category. Package it as a tarball, with out of band instructions or a script to untar the tarball in one of /tmp or /var/tmp (don't assume ... check and see). Copy the unpacked files into /opt/${NAME_OF_SOFTWARE} in the appropriate forms if they need to be modified or compiled at install time. Put any host-wide restricted-to-root config files in /etc/${NAME_OF_SOFTWARE}. Put the front-end starter script for it in /usr/local/bin. If daemons are involved, find the appropriate installer tool and call it, or hunt for an appropriate init directory (the install script will need to have some logic here to figure this out). And keep a log of all the steps performed, and a list of files installed, in a file named /var/log/${NAME_OF_SOFTWARE}/${yyyy}-${mm}-${dd}-${HH}${MM}-install.log.

    And you can do BSD, too, though most likely with different executables. There aren't so many BSDs, so this part should be easier.

    This is not that hard, people. Especially for programmers. Stop whining about Linux not being as boring as Windows is.

  20. Re:Just what the world needed on Bedrock Linux Combines Benefits of Other Linux Distros · · Score: 1

    It's only a drop in the bucket.

  21. Eventually it will be outlawed ... on UEFI Secure Boot and Linux: Where Things Stand · · Score: 1

    ... in some country. Then there will be ARM devices around that can boot whatever you want. Said country will get rich re-exporting more useful hardware back to the world.

  22. Re:Is EVERYONE on Slashdot COMPLETELY RETARDED? on UEFI Secure Boot and Linux: Where Things Stand · · Score: 1

    This only works on x86. You forgot about ARM.

  23. Re:This is why I hate Microsoft on UEFI Secure Boot and Linux: Where Things Stand · · Score: 1

    Just buy from a known Linux vendor, such as eRack.com or System76.com. I'm sure there are some others.

  24. Re:Just like the no-fly list? on Google+ Account Suspended? You Won't Find Out Why · · Score: 2

    And you believe cops care about what someone on the other end of a phone call says?

  25. Re:Just like the no-fly list? on Google+ Account Suspended? You Won't Find Out Why · · Score: 1

    So Google does not own up to it's mistakes? Oh wait ...