github as it exists now was never going to last forever. At some point the VC firms that funded github were going to cash out. They'd either take it public or arrange an acquisition. That's how this works.
Install a dropbox to receive packages. Same thing UPS and FedEx use. Easy to put stuff in, but hard to get anything out unless you have the key to open it.
4. There is zero commercial advantage in releasing the source.
I'm not so sure about that. I think with proper marketing AMD could turn it into a major commercial advantage. Imagine the ad campaign...
AMD chips don't spy on you, and we can prove it.
Intel is hiding behind lawyers and refusing to come clean.
Which one do you want inside your computer?
(Unfortunately, "proper marketing" and "AMD" are rarely used in the same sentence.)
... however it's worth noting that there are currently no ways of finding a collision for both MD5 and SHA-1 hashes simultaneously
Any crypto geeks want to weigh in on the truth of this statement? I've often wondered about this. Wouldn't using two hash algorithms be easier and more effective over the long term than getting the whole world to upgrade to the Latest And Greatest Hash every ~10 years?
I get why sites like Network World and BetaNews avoid linking to the subject of their articles. Heaven forbid a reader click the link and leave their site, possibly never to return! Won't somebody please think about the advertisers! Reasonable financial motives for bad behavior doesn't change the fact that it's bad behavior.
I'm old enough to remember the days of 8-bit computing and the ubiquity of BASIC. Those were good times, but the world has moved on. The problem isn't the language -- GUI's simply changed the rules of the game.
Text (command line) programs can naturally be written a linear procedural fashion. Cause and effect are clear. Display something, wait for input, act on input, rinse, and repeat. Classic BASIC fit this model well, and people could easily learn it. You could go from zero to useful in a relatively short time.
At a technical level, GUI programming is inherently event driven. Originally this took the form of event loops dispatching messages, with more object oriented approaches evolving over time. Classic BASIC does not fit this model, but can be extended to do so (e.g. Visual BASIC). The problem is that the learning curve is steeper. Event driven programming is hard for non-programmers to wrap their minds around.
Another problem is that modern computers come with lots of beautiful GUI-based software, and creating similar software takes considerable knowledge and effort. It's MUCH harder for a newbie to create software that looks and feels like "professional" programs. I imagine this could be very discouraging. I clearly remember the feeling of pride and accomplishment I felt back in the 8-bit days, when my own programs met, and then exceeded the standards of the day. I was able to go from zero to that place in a reasonable amount of time; now it might take years.
A group representing psychopaths issued a statement saying that the laws against murder had 'gone too far". They particularly complained that legislators focused primarily on the public interest, and failed to balance those concerns against the needs of killers.
The Body Electric is Rush at their best. The bass and drums on the intro are instantly recognizable. It's one of several tracks on the Grace Under Pressure album (released in 1984) that showcase the classic Rush sound.
Few rock bands dare to address "heavy" topics, but Rush did it regularly, and with great success. Neal Peart's skill with lyrics is on full display here. Grace Under Pressure included songs about artificial life ("The Body Electric"), the holocaust ("Red Sector A"), and the cold war ("Distant Early Warning"). None are "preachy", and all are quite accessible to mainstream audiences. They all received a good amount of airplay on rock radio.
(Yes, I'm a huge Rush fan, and I'm proud to admit it!)
Just because one compiler for one platform fails to support a popular C extension doesn't mean the library isn't portable.
Except that the one platform is Windows, which accounts for the vast majority of desktop PC's and laptops, and a significant chunk of servers. And the one compiler is the standard for Windows, used by the vast majority of Windows developers.
You don't have to like this, but it is the truth.
In my opinion, any software that can't compile on Windows using the native toolchain doesn't qualify as "portable". That doesn't make it bad software. It just isn't "portable" software.
I know there's a guy working on Windows support as well.
Let me know what the guy working on Windows support actually gets it working. Until then it doesn't count. And by "working", I mean working with the Microsoft toolchain, which like it or not, is the official and most widely used toolchain for Windows.
libressl is NOT portable. Supporting BSD and Linux is not the definition of "portable" (see also: "We play both types of music: Country and Western"). The libressl code depends on the non-standard #include_next preprocessor directive, so it can only build with GCC (and probably clang, which emulates many GCC-isms). Forget about building on Windows using Microsoft's C compiler.
OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.
... check out OpenBSD before checking out FreeBSD, and I cannot stress this enough. FreeBSD developers don't use their own operating system; they run it in a Virtual machine on their Macs, and it shows.
Citation needed.
Suspend/resume has been broken there since 2008, and drivers for any recent Intel graphics adapter will not run (you cannot switch from Xorg to a console and back) properly.
Yeah, it can suck to run a server-focused OS on a desktop/laptop.
FreeBSD devs do not care about their OS
This is objectively false. Any devs working for free must care, of they'd hack on something else. Any devs being paid must have an employer who cares. The problem is that the people hacking/funding FreeBSD don't care about the same parts of the system that you do.
... the way systemd has turned into something similar to the bloated beast that is the Windows 'svchost.exe'...
+1 to the anti-systemd sentiment.
-1 to using svchost.exe to make your case. svchost is just a container process. The real issue is the Windows architecture/philosophy that encourages a proliferation of services.
(I like Unix and I like Windows. Each has their place. Trying to turn one into the other is a big mistake.)
Option #1: Valve has no physical presence in Australia, and tells the Australian government to go fuck themselves. Government responds by banning Valve from doing business in Australia. Good luck enforcing that. To the extent they do manage to enforce it, it will be taking action against Australian citizens, since they have no power over Valve.
Option #2: Valve doubles prices in Australia. Y'all can have all the consumer protection you want, but you're going to pay for it.
(1) Press F8 during boot to get to the Windows boot manager advanced options screen.
(2) Select "Repair".
(3) Provide password for a local account that's a member of the Administrator group.
(4) Select "Command Prompt".
(5) Find drive letter assigned to Windows partition (may not be C: in the repair environment!).
(6) Delete \Windows\System32\FNTCACHE.DAT.
(7) Exit command prompt and reboot system.
(8) Fixed!
----------
And now, since this is/., here is the required Windows bashing...
This bug demonstrates the danger of running your GUI in kernel mode (win32k.sys). One stray pointer can ruin your whole day. In this case the pointer was sufficiently invalid to cause a bugcheck. A stray pointer that silently scribbles on other kernel data structures is even worse.
"Those who would give up essential Safety, to purchase a little temporary Performance, deserve neither Performance nor Safety."
I think NVidia tied their hands by retaining the ARM architecture. I suspect the result will be a "worst of both worlds" processor that doesn't use less power or provide better performance than competitors.
In order execution, exposed pipelines, and software scheduling are not new ideas. They sound great in theory, but never seem to work out in practice. These architectures are unbeatable for certain tasks (e.g. DSP), but success as general purpose processors has been elusive. History is littered with the corpses of dead architectures that attempted (and failed) to tame the beast.
Personally, I'm very excited about the Mill architecture. If anybody can tame the beast, it will be these guys.
Splits in the circuits are more common than you might imagine, and the Supreme Court doesn't always resolve them. A lot depends on how substantial the split is. Minor differences don't always get resolved.
In any event, this case isn't "ripe" for appeal to the Supreme Court yet. The Supremes rarely get involved until all lower court proceedings have been exhausted, and this case just got sent back for retrial on the issue of fair use. The process can be maddening for the individual litigants, but it makes sense for the legal system overall.
(I actually read the court ruling before posting this)
tl;dr version: The results will likely be awful, but the decision appears legally correct.
Google won at trial because the judge decided that the Java API was not copyrightable. I absolutely believe that API's should not be copyrightable, but that isn't what the law says. Copyrightability has a very low threshold. The trial judge screwed up by applying legal standards related to fair use to the question of copyrightability. The appeals court was correct to reverse.
The case now goes back to the district court. There will be a new trail with a new jury, but the only issue will be whether Googe's copying of the Java API is fair use. The original jury deadlocked on this question. Fair use decisions are very subjective, so it's hard to predict how this will turn out. All I can say is that I hope Google wins.
P.S. None of this decision was related to patents. Oracle lost on their patent claims at trial, and that stands.
At the macro level, adding employment to Detroit would be a good thing. At the micro level, it could be a bad thing for individuals who take a job at GM, and then find themselves working in conditions that make Dilbert look good by comparison. I understand "any port in a storm, and any job in a recession." But if you have a choice, would you really want to go to work for somebody who is absolutely hated by many of his prior employees?
Anybody thinking of getting an IT job at GM should talk to somebody who worked under Randy Mott at one of his previous gigs (e.g. Wal-Mart, Dell, HP). You won't find many fans.
Slashdot Mirror
github as it exists now was never going to last forever. At some point the VC firms that funded github were going to cash out. They'd either take it public or arrange an acquisition. That's how this works.
Install a dropbox to receive packages. Same thing UPS and FedEx use. Easy to put stuff in, but hard to get anything out unless you have the key to open it.
4. There is zero commercial advantage in releasing the source.
I'm not so sure about that. I think with proper marketing AMD could turn it into a major commercial advantage. Imagine the ad campaign...
AMD chips don't spy on you, and we can prove it.
Intel is hiding behind lawyers and refusing to come clean.
Which one do you want inside your computer?
(Unfortunately, "proper marketing" and "AMD" are rarely used in the same sentence.)
Each archetype really needs a picture!
See the Flame Warriors Guide as an example.
LEO satellites aren't worth it. You get high latency and high cost.
I expect Google will end up deploying a wireless network based on RFC1149. The latency sucks, but you can't beat the price.
Any crypto geeks want to weigh in on the truth of this statement? I've often wondered about this. Wouldn't using two hash algorithms be easier and more effective over the long term than getting the whole world to upgrade to the Latest And Greatest Hash every ~10 years?
Neither of TFA's or the /. summary provide a link to Clear Linux. WTF?!?!
Here it is: https://clearlinux.org/
I get why sites like Network World and BetaNews avoid linking to the subject of their articles. Heaven forbid a reader click the link and leave their site, possibly never to return! Won't somebody please think about the advertisers! Reasonable financial motives for bad behavior doesn't change the fact that it's bad behavior.
I'm old enough to remember the days of 8-bit computing and the ubiquity of BASIC. Those were good times, but the world has moved on. The problem isn't the language -- GUI's simply changed the rules of the game.
Text (command line) programs can naturally be written a linear procedural fashion. Cause and effect are clear. Display something, wait for input, act on input, rinse, and repeat. Classic BASIC fit this model well, and people could easily learn it. You could go from zero to useful in a relatively short time.
At a technical level, GUI programming is inherently event driven. Originally this took the form of event loops dispatching messages, with more object oriented approaches evolving over time. Classic BASIC does not fit this model, but can be extended to do so (e.g. Visual BASIC). The problem is that the learning curve is steeper. Event driven programming is hard for non-programmers to wrap their minds around.
Another problem is that modern computers come with lots of beautiful GUI-based software, and creating similar software takes considerable knowledge and effort. It's MUCH harder for a newbie to create software that looks and feels like "professional" programs. I imagine this could be very discouraging. I clearly remember the feeling of pride and accomplishment I felt back in the 8-bit days, when my own programs met, and then exceeded the standards of the day. I was able to go from zero to that place in a reasonable amount of time; now it might take years.
A group representing psychopaths issued a statement saying that the laws against murder had 'gone too far". They particularly complained that legislators focused primarily on the public interest, and failed to balance those concerns against the needs of killers.
YouTube video: https://www.youtube.com/watch?...
The Body Electric is Rush at their best. The bass and drums on the intro are instantly recognizable. It's one of several tracks on the Grace Under Pressure album (released in 1984) that showcase the classic Rush sound.
Few rock bands dare to address "heavy" topics, but Rush did it regularly, and with great success. Neal Peart's skill with lyrics is on full display here. Grace Under Pressure included songs about artificial life ("The Body Electric"), the holocaust ("Red Sector A"), and the cold war ("Distant Early Warning"). None are "preachy", and all are quite accessible to mainstream audiences. They all received a good amount of airplay on rock radio.
(Yes, I'm a huge Rush fan, and I'm proud to admit it!)
Get your own domain name.
Pay for your own hosting.
Post whatever you want.
Move to a new host any time you feel the need.
Problem solved.
IMHO, it's foolish to trust a free service to host something you care about and want to see continue indefinitely.
Just because one compiler for one platform fails to support a popular C extension doesn't mean the library isn't portable.
Except that the one platform is Windows, which accounts for the vast majority of desktop PC's and laptops, and a significant chunk of servers. And the one compiler is the standard for Windows, used by the vast majority of Windows developers.
You don't have to like this, but it is the truth.
In my opinion, any software that can't compile on Windows using the native toolchain doesn't qualify as "portable". That doesn't make it bad software. It just isn't "portable" software.
libressl supports pretty much any unix-like OS
Oh good, both Country and Western.
I know there's a guy working on Windows support as well.
Let me know what the guy working on Windows support actually gets it working. Until then it doesn't count. And by "working", I mean working with the Microsoft toolchain, which like it or not, is the official and most widely used toolchain for Windows.
libressl is NOT portable. Supporting BSD and Linux is not the definition of "portable" (see also: "We play both types of music: Country and Western"). The libressl code depends on the non-standard #include_next preprocessor directive, so it can only build with GCC (and probably clang, which emulates many GCC-isms). Forget about building on Windows using Microsoft's C compiler.
OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.
... check out OpenBSD before checking out FreeBSD, and I cannot stress this enough. FreeBSD developers don't use their own operating system; they run it in a Virtual machine on their Macs, and it shows.
Citation needed.
Suspend/resume has been broken there since 2008, and drivers for any recent Intel graphics adapter will not run (you cannot switch from Xorg to a console and back) properly.
Yeah, it can suck to run a server-focused OS on a desktop/laptop.
FreeBSD devs do not care about their OS
This is objectively false. Any devs working for free must care, of they'd hack on something else. Any devs being paid must have an employer who cares. The problem is that the people hacking/funding FreeBSD don't care about the same parts of the system that you do.
... the way systemd has turned into something similar to the bloated beast that is the Windows 'svchost.exe' ...
+1 to the anti-systemd sentiment.
-1 to using svchost.exe to make your case. svchost is just a container process. The real issue is the Windows architecture/philosophy that encourages a proliferation of services.
(I like Unix and I like Windows. Each has their place. Trying to turn one into the other is a big mistake.)
Option #1: Valve has no physical presence in Australia, and tells the Australian government to go fuck themselves. Government responds by banning Valve from doing business in Australia. Good luck enforcing that. To the extent they do manage to enforce it, it will be taking action against Australian citizens, since they have no power over Valve.
Option #2: Valve doubles prices in Australia. Y'all can have all the consumer protection you want, but you're going to pay for it.
The way to fix this is to delete \Windows\System32\FNTCACHE.DAT. The file will automatically be regenerated on the next boot.
(Information found on Microsoft Support Forum and used to successfully fix my own system.)
How do you delete the file if you can't boot?
(1) Press F8 during boot to get to the Windows boot manager advanced options screen.
(2) Select "Repair".
(3) Provide password for a local account that's a member of the Administrator group.
(4) Select "Command Prompt".
(5) Find drive letter assigned to Windows partition (may not be C: in the repair environment!).
(6) Delete \Windows\System32\FNTCACHE.DAT.
(7) Exit command prompt and reboot system.
(8) Fixed!
----------
And now, since this is /., here is the required Windows bashing...
This bug demonstrates the danger of running your GUI in kernel mode (win32k.sys). One stray pointer can ruin your whole day. In this case the pointer was sufficiently invalid to cause a bugcheck. A stray pointer that silently scribbles on other kernel data structures is even worse.
"Those who would give up essential Safety, to purchase a little temporary Performance, deserve neither Performance nor Safety."
I think NVidia tied their hands by retaining the ARM architecture. I suspect the result will be a "worst of both worlds" processor that doesn't use less power or provide better performance than competitors.
In order execution, exposed pipelines, and software scheduling are not new ideas. They sound great in theory, but never seem to work out in practice. These architectures are unbeatable for certain tasks (e.g. DSP), but success as general purpose processors has been elusive. History is littered with the corpses of dead architectures that attempted (and failed) to tame the beast.
Personally, I'm very excited about the Mill architecture. If anybody can tame the beast, it will be these guys.
Splits in the circuits are more common than you might imagine, and the Supreme Court doesn't always resolve them. A lot depends on how substantial the split is. Minor differences don't always get resolved.
In any event, this case isn't "ripe" for appeal to the Supreme Court yet. The Supremes rarely get involved until all lower court proceedings have been exhausted, and this case just got sent back for retrial on the issue of fair use. The process can be maddening for the individual litigants, but it makes sense for the legal system overall.
(I actually read the court ruling before posting this)
tl;dr version: The results will likely be awful, but the decision appears legally correct.
Google won at trial because the judge decided that the Java API was not copyrightable. I absolutely believe that API's should not be copyrightable, but that isn't what the law says. Copyrightability has a very low threshold. The trial judge screwed up by applying legal standards related to fair use to the question of copyrightability. The appeals court was correct to reverse.
The case now goes back to the district court. There will be a new trail with a new jury, but the only issue will be whether Googe's copying of the Java API is fair use. The original jury deadlocked on this question. Fair use decisions are very subjective, so it's hard to predict how this will turn out. All I can say is that I hope Google wins.
P.S. None of this decision was related to patents. Oracle lost on their patent claims at trial, and that stands.
IBM, Dell, and Cisco already do the same thing.
Just curious... Have you tested x265 scalability on any big iron? (e.g. eight socket Xeon server)
At the macro level, adding employment to Detroit would be a good thing. At the micro level, it could be a bad thing for individuals who take a job at GM, and then find themselves working in conditions that make Dilbert look good by comparison. I understand "any port in a storm, and any job in a recession." But if you have a choice, would you really want to go to work for somebody who is absolutely hated by many of his prior employees?
Anybody thinking of getting an IT job at GM should talk to somebody who worked under Randy Mott at one of his previous gigs (e.g. Wal-Mart, Dell, HP). You won't find many fans.