Have you considered that it would've taken lots longer for oracle to give up the code, if the devs had stayed? And it might've not happened at all. Of course you haven't.
If Oracle had managed the project at all instead of just not saying anything LibreOffice probably wouldn't exist. Most in the community jumped because Oracle wasn't saying anything - period.
Now, if Oracle had done something other than what it did, then OpenOffice would probably be in a state similar to MySQL. May be LibreOffice would exist, but not likely since there was no OpenOffice equivalent of Michael Widenius.
Not to mention that at the point where oracle gave the code, there was lots and lots of done for libre office.
The devs that continue just worked on a lot of technical debt. But they did so at the expense of any future integration with any OpenOffice related project because of the license changes and the fact that they were pretty much guaranteed that the licensing used by LibreOffice would prohibit contributions back to OpenOffice regardless of what happened.
Sure it'd be nice to be able to combine the effort, but licensing does not allow that.
IIRC, that was purposeful, and also a side-effect.
I don't have anything against open office, but i'm not going to change from libre office until open office is not only to the par with libre office, a lots better than libre office.
Fair enough. I prefer OpenOffice over LibreOffice. To each their own.
But seriously, your description of libre office people running at first sign of trouble is complete bullshit. You are a douche, there's no way around that fact.
Well, it wasn't really a "first sign of trouble". It was a lack of trust in Oracle, lack of any communications from Oracle, etc - there were numerous and valid reasons for it. That said, the LibreOffice community also has its own issues in that respect. I participated in the early community building and dropped out when it was clear what kind of community was being formed - and it wasn't what was being advertised. May be that's changed; I don't know - but I'm still not really interested in LibreOffice seeing the product they've put out, I personally find it inferior to OpenOffice.
Grab LibreOffice and check it out. If startup time is a key point for you, install and enable the QuickStart feature. It'll pre-load part of LibreOffice as Windows starts up and then let it sit idle in the background, just like Microsoft Office does to improve startup time.
FYI - OpenOffice has long had that feature, even back in version 3.0.
You've got it the wrong way around license-wise. LibreOffice can pull anything they'd like from OpenOffice, but OpenOffice won't because they don't want LGPL/GPL code polluting their code-tree. OpenOffice spent a long time rewriting GPL/LGPL code to ensure they could keep their license pure which is one of the reasons they're so much further behind LibreOffice.
That's what I said. The "they" in the GP consistently referred to LibreOffice.
LibreOffice uses the GPL/LGPL code because they had no choice - it was the only option available to them since they were forking the source code.
OpenOffice is purely and solely licensed under Apache License version 2. They also didn't have to rewrite code for GPL/LGPL compliance - Oracle wholesale relicensed the work to Apache version 2 before they could contribute it to Apache to start with. A lot of their time was in integrating IBM's Symphony changes, and catching backup after several months of minimal to no development going on; but they've re-established that.
So LibreOffice can pull chances from OpenOffice since Apache License V2 code can be easily relicensed to GPL/LGPL, but OpenOffice cannot pull changes from LibreOffice.
So what is the story between the two? I know that LibreOffice is a fork of OpenOffice and that some/most/all of the devs moved to LibreOffice.
Is LibreOffice now far enough ahead to say forget about OpenOffice?
LibreOffice is moving on its own. They do fix some things ahead of OpenOffice, but they also continue to borrow code from OpenOffice. Licensing-wise, they're more limited than OpenOffice is so the code-sharing is not a two-way street, they take but they can't contribute back.
Personally, I still prefer OpenOffice. I recently accidentally opened up-to-date LibreOffice Calc on Kubuntu 15.04 and the interface was just horrid.
Yes more expensive per bulb, but not more expensive when it comes to replacing bulbs. Much cheaper than CFLs in my view, for incandescent you just have to wait longer to amortize the cost.
I used to always have a few incandescent boxes because they were always burning out (it varies, I have one fixture that I haven't ever replaced a bulb in, and others where I replace them often).
That's because incandescents are sensitive to the quality of the fixture and electricity that they are receiving. If you have fixture that doesn't regulate power well, then you'll got through more bulbs; if you have very bad electricity supply (too much/little power in fluctuations) then you'll also go through more bulbs. This is because the bulbs typically directly receive electricity from the power outlet - no regulation, so too much power the bulb gets brighter; too little it dims.
CFL and Fluorescent bulbs overcome that through a regulator in the fixture (aka ballast), and sometimes a fuse as well; and the regulator gets destroyed instead.
LEDs overcome it by the chips in the bulb itself which operate as a regulator, and will probably get destroyed before the LED bulb itself is useless. I have no clue, however, what the quality of the electricity supply or fixture will do to an LED bulb though.
I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...
Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.
Let's say that I have a file, a plain text file, and I put it into a password protected.zip file. That new file, the.zip, would then be encrypted, as a whole, into a new file - say file.tar.bz. Now, to open it, you would need to have the shared key PLUS you would need to know the password to the encrypted.zip file.
I understand that this has nothing to do with TLS and would be wholly impractical for browsing. However, the talk of encryption made me wonder about this and I have been pondering this for a couple of years now. It means it would be something you have and something you know.
Yes you can encrypt and encrypted file - just as you described. However, you have to use a different crypto keyset to do it or you defeat the encryption by revealing too much information.
I can think of many ways to share the needed password/pass-phrase securely (for certain definitions of securely). Say, five books in a certain order on a bookshelf and calling with a series of numbers which determine with pages and words are used to make up the pass-phrase. A call could be as simple as, "Number 3, 27, 5, 18, number 7, 14, 32, 8. Confirm?" Which would be book number 5, chapter 3, 27th page, fifth and eighteenth words and book seven, chapter fourteen, thirty second and eighth word would be the password. This does not help if there is someone physically present.
That was done extensively throughout the Cold War, and is a common use of OTP. It's highly secure, and very difficult to break due to that exact kind of thing.
Anyhow, there may be some need to change the file type at the recipient's end because decrypting the file.tar.bz file will not necessarily mean that the file has the appropriate.zip extension but, well, that is pretty trivial.
What am I missing? This, obviously, has absolutely no value in the real world for almost every single person on the planet. I could see it being useful for TLAs or those who are trying to subvert their government (for a variety of reasons which may be good or bad).
To start, most software detects file types based on the content, not the file names. They may use a file extension as a basic filter, but often that's more of a user-interface kind of thing than anything else. So changing the file type is not really a help of any kind, it barely even obfuscates things - smart filters will adjust accordingly, and we've seen those plenty in email systems that appropriately detects "piz" files a "zip" files, etc.
No; a true OTP is NOT the same as pseudo-random OTP.
I said using an RNG not a PRNG.
A synchronized RNG is generated by synchronizing the clocks on the hardware, and initial seed data. True, it's not a fully random RNG, but it is sufficient for the needs of a OTP crypt/decrypt function as I described.
I also never said it was perfect; just theorizing on a way that you could do it with shared hardware instead of having to share an enormous file.
In reality, nobody uses a OTP because if you can securely communicate the length of the pad, you can just as easily communicate the entire message. What is used instead is public-key encryption where your partner can encrypt a message, but only you can decrypt it.
And yes, OTP has been used to securely communicate many things. In many senses, the Enigma machine is a OTP kind of system using a hardware dataset as the pad; it's no considered such because it didn't do the normal XOR operation associated with OTP functionality, but is also has the same flaws.
In reality, OTP is used with a large dataset to securely communicate messages when you want to ensure that no MITM attack can be possible, and you may have multiple receivers. OTP was a common means of communication for the Cold War - know what book to pick up, page to start with, etc. It's a very secure means of communication; and it still used for secure communications today.
Like it or not, any means of setting up a security context (Diffie-Hellman, TLS, etc) is susceptible to MITM attacks (during the security context creation, and therefore extending to the rest of the session) due to the simple fact that you have to dynamically create the security context. The only resolution to that is an OTP security context.
Well, my favorite bug of my own was in a batch file I put on a Win95 system to clean out the Temporary Internet directory; only it didn't change its working directory and ended up deleting stuff from the Windows directory instead...learned that Win95 can be installed over itself at run-time, thus saving the system before I rebooted it.
That said, I'm a strong believer in defensive programming practices. Not only do they make the software more secure, but they also help catch your own bugs. As the one article in TFS says
Unless out-and-out performance is vital, checking inputs is always a good idea.
Hint: Performance is only vital in very few locations, namely interrupt handlers deep in the Operating System. So it's not likely that performance is vital enough to skip checking the inputs to your functions.
Hint: Checking the inputs to your functions will almost always help you catch logic errors, prevent memory overflows, etc. IOW, they'll save you many man months of debugging by making many things obvious. You just have to be disciplined enough to do them.
You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap
You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.
There is literally no security difference between these two pads:
XOJIGQIOJG
XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG
(for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).
There is no requirement to skip a character in one-time pads. You can read sequential bytes without any issue. That said, how you use the one-time pad data can certainly contribute to its worth or worthlessness.
Supposing that the first example is used as is, and the second example all the A's are skipped, that that's correct - there is no difference. However, there is a big difference if in the second example you don't skip the A's - the pad is degrading your security as it's not sufficiently random.
That said, you could probably use a synchronized random number generator as the shared pad data.
That's what mathematical ciphers do -- they establish a synchronized pseudo-random number generator. A synchronized truly random number generator is almost a contradiction in terms, although quantum encryption does provide a way to transmit truly random information to exactly one recipient, which is pretty much a synchronized true RNG.
I did not say using a PRNG, but an RNG - think RSA token. We have plenty of synchronized hardware-based RNGs that we use for authentication. You would just need to up the rate of the number generation, which may make it harder to maintain synchronization. RSA tokens are good for a couple years, but only generate numbers every 60 seconds.
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).
There's a big difference:
With a normal cipher stream (RC4, etc) it's data that is shared on the fly to create the cipher stream in a shared state (TLS, Diffie-Hellman, etc). The fact that you have to create it on the fly leads to vulnerabilities and MITM attacks.
Conversely with the one-time pad you have all the data pre-shared; in my example of using an RNG (not a PRNG) - it's a synchronized hardware device that is shared. This is why a one-time pad is more secure than any normal cipher stream.
However, the problem with using an RNG is that the clocks can skew between the two devices over time. So it's not a very good source.
I never liked CFLs, they burned out as fast as my incandescents did, not even long enough to cover the cost of energy to make them. LED lights though seems a better deal overall; more expensive but also longer lasting with an even lower energy cost.
What I like about LEDs is that they are generally solid-state, so less prone to breaking.
What I don't like is the cost, and the reliance on chips to run them...at least, the ones that replace the normal lightbulb sizes...not to mention the price.
A large number of people religiously state Software Patents are evil and should never be permitted.
If the claims by Microsoft are true, then a Patent should be granted for this "mathematical" discovery.
It is a significant improvement in security over existing encryption, and so deserves Patent protection.
Except math is explicitly forbidden from being patented.
I think that Patents should only protect PUBLICLY AVAILABLE products.
In this case Microsoft can sell IIS Server / Edge Web browser ($0 cost) with enhanced encryption and the Patent will protect them from competition.
Patent Trolls should be destroyed. They way to do this is to only allow legal action if you actually sell a product and other companies are reducing your sales or profits. If there is no reduction in sales or profits, your maximum gain from a Patent should be limited to $0.
They only way you destroy patent trolls is by tying money earned from the patented invention to the cost of developing the patented invention along with some percentage of profits. Thereby, if it costs $1 to create the patented invention you get to hold the patent until you earn $1 and the percentage of profits, which would happen really quickly (sell it one time); it it costs $1000 or $1,000,000 then you would hold it longer - e.g the market decides how long you get to hold it; outright sale of the patented invention to a third party would nullify the patent itself since you would have recouped the costs, and the prime motivator for patents is therefore enforced - that inventors be encouraged to invent new things - while equally destroying the troll market.
OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
Not quite. You can't repeat the pad the same way ever - that is, you don't want to wrap it or reset to known locations using any kind of protocol. You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap. So you're data limited unless you have an infinite data source.
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
LEDs are more expensive but they also have a higher potential lifespan than incandescent or CFL bulbs. They also have a lower power draw so unless we don't see the lifespan that they promise LEDs are probably a cheaper cost of ownership compared to incandescent bulbs.
True, supposedly so. I know I rarely changed an incandescent - probably once every couple years at most; I usually changed an incandescent because the bulb broke due to the lamp getting knocked over more than anything else - actually seeing the EOL of an incandescent was rare. I expect it will probably be the same with LEDs and CFLs; though LEDs will probably be because the electronics in their base die - capacitors drying out, etc; which will be a lot harder to test what is wrong with them.
They do have the higher capital cost, as you pointed out, but that means more that it prices them out of the range of lower income families who will be forced into the higher cost of ownership CFLs.
Which has the funny aspect of exposing those folk to mercury contamination...
Honestly, we shouldn't be trying to force the public to use one over the other. Let people choose free market style. There was no reason for the EPA to get involved in this. Would people still buy incandescents? Yes; but most would probably skip CFLs and go straight to LEDs as well - which were not really even part of the picture when Congress passed the bill mandating incandescents be phased out; and the phase out had little to nothing to do with the introduction of LEDs when they came.
So a single LED bulb at a sale discount, versus 8 incandescent bulbs. FYI - average price of a single LED bulb is $7+ for 40/60/75/100W bulbs before any sale discounts.
Average prices for a 4 or 8 package of incandescent bulbs before any sale discounts was $2-3; I typically paid $1 for a 4 package at most.
Best price I've seen for CFLs was the occasional Sam's Club pack for $1 containing 8 CFLs (40/60/75/100W); but that's rare. Typically the same pack age Sam's Club is $8+.
And after our 4 yr old broke a CFL in his room (since we couldn't put a new Incandescent in), we replaced it with an LED, which I'd much prefer if not for the expense. Even then, the first one didn't work for some reason; fortunately the store did a return/exchange and the second one (a different brand) worked.
Well you would also benefit if you bought the newer, more efficient cars.
So what, exactly, is the problem here?
So here's the deal:
Catalytic Converter: Costs vehicles gas mileage for a minimal return on emissions
Ethanol #1: Costs all vehicles (new and old) gas mileage; the higher the mixture the worse the mileage - this is all simple fact because even the best ethanol does not contain as much energy as the worse petroleum products.
Ethanol #2: Actively damages older vehicles, and has lead to numerous leaks when it corrodes through the seals on gas tanks; it also damages boats and nearly all small motors; many small motors (used for lawn care) end up getting thrown out every couple years for no reason other than ethanol damage and it's usually cheaper to replace than fix - again, this is well known because all ethanol is highly corrosive.
Incandescent Light bulbs are being phased out in favor of CFLs since CFLs use less energy, though they cost more to buy (as do LED bulbs, which are more expensive yet). CFLs like their bigger fluorescent versions use mercury; so dropping and breaking a light bulb can now lead to mercury contamination at a greater scale. Despite this, EPA is focused on removing mercury from power plants which produce less mercury than breaking one of those CFL bulbs. And they've also made a great way to shutdown a store - go break all the CFLs so they have to call in a hazmat team to clean up the mercury contamination. (LEDs do solve this particular issue, but tend to cost 2-5x's more than CFLs which already were 10'x the cost of an incandescent.)
The list goes on.
Now I'm not saying that reducing emissions is not a good thing; or that reducing energy consumption is not a good thing - they are. However, when the cost of doing so ends up incurring an overall higher emissions rate, or more things to be toss out (thus increasing garbage and land-fills), etc...it's over impact is not worth the minor reduction in emissions.
One of Intel's major chip fabs is in China, so the chips can just be produced at that facility.
Also, if the US bans exports, then it's likely that Intel would move existing US based chip fabs to Europe
That all depends on the type of ban.
For instance, a sale ban would still effect the company regardless of which of it's international subsidiary's did the actual sale.
A design ban would forbid them from designing in the US and exporting the design to facilities elsewhere to even produce chips matching the design.
There have been electric delivery trucks for a long time - for example, Smith Electric Vehicles has been making li-ion trucks almost as long as Tesla has been around. And they follow up on a long history of electric delivery vehicles on a continuous line dating back to the early lead-acid days. But "existing" doesn't mean "having blown the market wide open". The big question is when that could happen.
You know, though, as ridiculous as it sounds, I almost wonder Tesla's efforts could evolve into a killer delivery vehicle. The Model S / Model X drivetrain is already starting to get into the power range of a big rig, and big rig budgets can afford their high prices. Combine that this potential solution to charging over long distances and you really could have a winner.
So the primary issue for Big Rig trucking is distance.
Drivers often fill up 100-200 gallon tanks, and cover large distances between stops. They might stop for fuel once a day, may be twice while covering 500-1000 miles. Can we build a big rig that has the torque capacity AND the distance requirements? May be.
But then, you also need to be able to manage the batteries well enough too, and be able to recharge quickly.
Battery swapping won't really work. Why? Who owns the batteries? Who's responsible for them? What places are going to swap out batteries?
If the owner of the vehicle owns the batteries, then swapping doesn't work. Someone that just bought the batteries isn't going to swap them for a set of used batteries - that's too expensive.
A network of battery renters could work, but then you have to be able to get to one of their approved locations for a battery swap, so it's not really feasible, though this solution could bring the cost of the big rigs down considerably since they wouldn't have to buy the extremely expensive battery packs with the big rig, just sign up to a renter network.
Even then, who's responsible for batteries when there are problems? Who pays the bill when the battery overheats and blows up? Or who sends out another vehicle to swap batteries when the drain too quickly and the vehicle is stranded?
Yes, lawyers can solve many of the questions, but until that happens in a manner acceptable to the industry then there are problems.
Also, realize that many big rigs are owned by their drivers. Independent truckers are quite common and many trucking companies prefer to use independent truckers over buying their own equipment; often paying barely enough for the guys to be able to maintain the vehicles - it's a very cut throat business. So those buying the big rigs don't necessary have budgets for expensive technology; they just want something that is going to work, work well, be easy to maintain, and be highly reliable - it's very expensive for them to get a tow (loss work, plus the cost of tow and maintenance). So it'll be a very up-hill battle to get them to accept electric vehicles.
For truckers to accept electric trucks, companies will have to get into it first. So FedEx proving that this vendor is reliable with their fleet will go a long way to bringing hybrids to trucking at all levels.
As to the transition of the technology from trains - the really big difference is that for the trains it's generally easy for them to know exactly how much fuel they need for the trip and how much to have in reserve. The fuel tanks are in the thousands of gallons, and they don't have to deal with traffic much. When they do, they'll know how long the wait will generally be and can handle the situation accordingly. It's also relatively easy for them to just fill up the tanks again. Just saying - the two industries are extremely different in many respects; so what one finds acceptable won't necessarily be so for the other.
Randomly, the pump will display "please see register for receipt" upon selecting the print option. I've see it being random as the person after me (a friend), had his receipt print just fine. It's a fucking scam to lure people into the store and buy shit.
Why waste paper getting a receipt? Your credit card company has a record of the transaction.
Because if you need to dispute it saying "I always get my receipts and I don't have one for that" works really well. Otherwise, you're at the mercy of your bank/card company to accurate report what you are spending - not a good habit to be in.
And frankly, current ranges on EV's make them pretty much useless for trucks. Who really wants to stop for a couple hours a couple times a day?
You won't see pure EV trucks for a long time. What you'll see is a power train similar to that on locomotives. Diesel engine charging electric motors with a battery bank to deal with the excess. It's very efficient, huge torque and the technology is well understood. I'm kind of surprised we aren't seeing it already.
We're starting to, but not in the big rigs; FedEx was reportedly doing a test on their delivery vehicles with a start up from South Carolina at a cost of $100k/vehicle upgrade. A few more players in the market, and the cost will drop significantly.
what's to stop a Waffle House, IHOP, or similar just having a charging stations outside? I think these "gas" stations or any future derivatives are dead, especially if commercial or environmental regulations are lifted/ nonexistent for electric charging stations.
Nothing; it's actually a perfect business for hotels, restaurants and entertainment venues to get into - put chargers in the parking lots to encourage people to stop in, add a small portion to the bill if they use the charge. They'll very quickly replace the gas stations, which no one really wants to stop at or go inside of.
The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.
Agreed. Any cross-platform projects needs to be able to support multiple build systems, whether you like it or not. Tools like CMake/QMake/Qbs/Ninja/etc are just essential.
I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.
Agreed. You have version control. That's all you really need. ChangeLogs are generally outdated and for releases (where the VCS won't be available) a dump of the logs in some form should be sufficient, provided you are writing meaningful log messages. IOW, good VCS practices are a must.
Slashdot Mirror
Have you considered that it would've taken lots longer for oracle to give up the code, if the devs had stayed? And it might've not happened at all. Of course you haven't.
If Oracle had managed the project at all instead of just not saying anything LibreOffice probably wouldn't exist. Most in the community jumped because Oracle wasn't saying anything - period.
Now, if Oracle had done something other than what it did, then OpenOffice would probably be in a state similar to MySQL. May be LibreOffice would exist, but not likely since there was no OpenOffice equivalent of Michael Widenius.
Not to mention that at the point where oracle gave the code, there was lots and lots of done for libre office.
The devs that continue just worked on a lot of technical debt. But they did so at the expense of any future integration with any OpenOffice related project because of the license changes and the fact that they were pretty much guaranteed that the licensing used by LibreOffice would prohibit contributions back to OpenOffice regardless of what happened.
Sure it'd be nice to be able to combine the effort, but licensing does not allow that.
IIRC, that was purposeful, and also a side-effect.
I don't have anything against open office, but i'm not going to change from libre office until open office is not only to the par with libre office, a lots better than libre office.
Fair enough. I prefer OpenOffice over LibreOffice. To each their own.
But seriously, your description of libre office people running at first sign of trouble is complete bullshit. You are a douche, there's no way around that fact.
Well, it wasn't really a "first sign of trouble". It was a lack of trust in Oracle, lack of any communications from Oracle, etc - there were numerous and valid reasons for it. That said, the LibreOffice community also has its own issues in that respect. I participated in the early community building and dropped out when it was clear what kind of community was being formed - and it wasn't what was being advertised. May be that's changed; I don't know - but I'm still not really interested in LibreOffice seeing the product they've put out, I personally find it inferior to OpenOffice.
Grab LibreOffice and check it out. If startup time is a key point for you, install and enable the QuickStart feature. It'll pre-load part of LibreOffice as Windows starts up and then let it sit idle in the background, just like Microsoft Office does to improve startup time.
FYI - OpenOffice has long had that feature, even back in version 3.0.
You've got it the wrong way around license-wise. LibreOffice can pull anything they'd like from OpenOffice, but OpenOffice won't because they don't want LGPL/GPL code polluting their code-tree. OpenOffice spent a long time rewriting GPL/LGPL code to ensure they could keep their license pure which is one of the reasons they're so much further behind LibreOffice.
That's what I said. The "they" in the GP consistently referred to LibreOffice.
LibreOffice uses the GPL/LGPL code because they had no choice - it was the only option available to them since they were forking the source code.
OpenOffice is purely and solely licensed under Apache License version 2. They also didn't have to rewrite code for GPL/LGPL compliance - Oracle wholesale relicensed the work to Apache version 2 before they could contribute it to Apache to start with. A lot of their time was in integrating IBM's Symphony changes, and catching backup after several months of minimal to no development going on; but they've re-established that.
So LibreOffice can pull chances from OpenOffice since Apache License V2 code can be easily relicensed to GPL/LGPL, but OpenOffice cannot pull changes from LibreOffice.
Having no release manager and no one contributing code for 9 months seems like more of a "Dead but hasn't stopped twitching" sort of state.
Dev and user lists are still very active. I would hardly consider AOO to be "dead" by any means.
So what is the story between the two? I know that LibreOffice is a fork of OpenOffice and that some/most/all of the devs moved to LibreOffice. Is LibreOffice now far enough ahead to say forget about OpenOffice?
LibreOffice is moving on its own. They do fix some things ahead of OpenOffice, but they also continue to borrow code from OpenOffice. Licensing-wise, they're more limited than OpenOffice is so the code-sharing is not a two-way street, they take but they can't contribute back.
Personally, I still prefer OpenOffice. I recently accidentally opened up-to-date LibreOffice Calc on Kubuntu 15.04 and the interface was just horrid.
Yes more expensive per bulb, but not more expensive when it comes to replacing bulbs. Much cheaper than CFLs in my view, for incandescent you just have to wait longer to amortize the cost.
I used to always have a few incandescent boxes because they were always burning out (it varies, I have one fixture that I haven't ever replaced a bulb in, and others where I replace them often).
That's because incandescents are sensitive to the quality of the fixture and electricity that they are receiving. If you have fixture that doesn't regulate power well, then you'll got through more bulbs; if you have very bad electricity supply (too much/little power in fluctuations) then you'll also go through more bulbs. This is because the bulbs typically directly receive electricity from the power outlet - no regulation, so too much power the bulb gets brighter; too little it dims.
CFL and Fluorescent bulbs overcome that through a regulator in the fixture (aka ballast), and sometimes a fuse as well; and the regulator gets destroyed instead.
LEDs overcome it by the chips in the bulb itself which operate as a regulator, and will probably get destroyed before the LED bulb itself is useless. I have no clue, however, what the quality of the electricity supply or fixture will do to an LED bulb though.
I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...
Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.
Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say file.tar.bz. Now, to open it, you would need to have the shared key PLUS you would need to know the password to the encrypted .zip file.
I understand that this has nothing to do with TLS and would be wholly impractical for browsing. However, the talk of encryption made me wonder about this and I have been pondering this for a couple of years now. It means it would be something you have and something you know.
Yes you can encrypt and encrypted file - just as you described. However, you have to use a different crypto keyset to do it or you defeat the encryption by revealing too much information.
I can think of many ways to share the needed password/pass-phrase securely (for certain definitions of securely). Say, five books in a certain order on a bookshelf and calling with a series of numbers which determine with pages and words are used to make up the pass-phrase. A call could be as simple as, "Number 3, 27, 5, 18, number 7, 14, 32, 8. Confirm?" Which would be book number 5, chapter 3, 27th page, fifth and eighteenth words and book seven, chapter fourteen, thirty second and eighth word would be the password. This does not help if there is someone physically present.
That was done extensively throughout the Cold War, and is a common use of OTP. It's highly secure, and very difficult to break due to that exact kind of thing.
Anyhow, there may be some need to change the file type at the recipient's end because decrypting the file.tar.bz file will not necessarily mean that the file has the appropriate .zip extension but, well, that is pretty trivial.
What am I missing? This, obviously, has absolutely no value in the real world for almost every single person on the planet. I could see it being useful for TLAs or those who are trying to subvert their government (for a variety of reasons which may be good or bad).
To start, most software detects file types based on the content, not the file names. They may use a file extension as a basic filter, but often that's more of a user-interface kind of thing than anything else. So changing the file type is not really a help of any kind, it barely even obfuscates things - smart filters will adjust accordingly, and we've seen those plenty in email systems that appropriately detects "piz" files a "zip" files, etc.
No; a true OTP is NOT the same as pseudo-random OTP.
I said using an RNG not a PRNG.
A synchronized RNG is generated by synchronizing the clocks on the hardware, and initial seed data. True, it's not a fully random RNG, but it is sufficient for the needs of a OTP crypt/decrypt function as I described.
I also never said it was perfect; just theorizing on a way that you could do it with shared hardware instead of having to share an enormous file.
In reality, nobody uses a OTP because if you can securely communicate the length of the pad, you can just as easily communicate the entire message. What is used instead is public-key encryption where your partner can encrypt a message, but only you can decrypt it.
And yes, OTP has been used to securely communicate many things. In many senses, the Enigma machine is a OTP kind of system using a hardware dataset as the pad; it's no considered such because it didn't do the normal XOR operation associated with OTP functionality, but is also has the same flaws.
In reality, OTP is used with a large dataset to securely communicate messages when you want to ensure that no MITM attack can be possible, and you may have multiple receivers. OTP was a common means of communication for the Cold War - know what book to pick up, page to start with, etc. It's a very secure means of communication; and it still used for secure communications today.
Like it or not, any means of setting up a security context (Diffie-Hellman, TLS, etc) is susceptible to MITM attacks (during the security context creation, and therefore extending to the rest of the session) due to the simple fact that you have to dynamically create the security context. The only resolution to that is an OTP security context.
That said, I'm a strong believer in defensive programming practices. Not only do they make the software more secure, but they also help catch your own bugs. As the one article in TFS says
Unless out-and-out performance is vital, checking inputs is always a good idea.
Hint: Performance is only vital in very few locations, namely interrupt handlers deep in the Operating System. So it's not likely that performance is vital enough to skip checking the inputs to your functions.
Hint: Checking the inputs to your functions will almost always help you catch logic errors, prevent memory overflows, etc. IOW, they'll save you many man months of debugging by making many things obvious. You just have to be disciplined enough to do them.
You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap
You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.
There is literally no security difference between these two pads:
XOJIGQIOJG XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG (for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).
There is no requirement to skip a character in one-time pads. You can read sequential bytes without any issue. That said, how you use the one-time pad data can certainly contribute to its worth or worthlessness.
Supposing that the first example is used as is, and the second example all the A's are skipped, that that's correct - there is no difference. However, there is a big difference if in the second example you don't skip the A's - the pad is degrading your security as it's not sufficiently random.
That said, you could probably use a synchronized random number generator as the shared pad data.
That's what mathematical ciphers do -- they establish a synchronized pseudo-random number generator. A synchronized truly random number generator is almost a contradiction in terms, although quantum encryption does provide a way to transmit truly random information to exactly one recipient, which is pretty much a synchronized true RNG.
I did not say using a PRNG, but an RNG - think RSA token. We have plenty of synchronized hardware-based RNGs that we use for authentication. You would just need to up the rate of the number generation, which may make it harder to maintain synchronization. RSA tokens are good for a couple years, but only generate numbers every 60 seconds.
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).
There's a big difference:
With a normal cipher stream (RC4, etc) it's data that is shared on the fly to create the cipher stream in a shared state (TLS, Diffie-Hellman, etc). The fact that you have to create it on the fly leads to vulnerabilities and MITM attacks.
Conversely with the one-time pad you have all the data pre-shared; in my example of using an RNG (not a PRNG) - it's a synchronized hardware device that is shared. This is why a one-time pad is more secure than any normal cipher stream.
However, the problem with using an RNG is that the clocks can skew between the two devices over time. So it's not a very good source.
I never liked CFLs, they burned out as fast as my incandescents did, not even long enough to cover the cost of energy to make them. LED lights though seems a better deal overall; more expensive but also longer lasting with an even lower energy cost.
What I like about LEDs is that they are generally solid-state, so less prone to breaking.
What I don't like is the cost, and the reliance on chips to run them...at least, the ones that replace the normal lightbulb sizes...not to mention the price.
A large number of people religiously state Software Patents are evil and should never be permitted. If the claims by Microsoft are true, then a Patent should be granted for this "mathematical" discovery. It is a significant improvement in security over existing encryption, and so deserves Patent protection.
Except math is explicitly forbidden from being patented.
I think that Patents should only protect PUBLICLY AVAILABLE products. In this case Microsoft can sell IIS Server / Edge Web browser ($0 cost) with enhanced encryption and the Patent will protect them from competition. Patent Trolls should be destroyed. They way to do this is to only allow legal action if you actually sell a product and other companies are reducing your sales or profits. If there is no reduction in sales or profits, your maximum gain from a Patent should be limited to $0.
They only way you destroy patent trolls is by tying money earned from the patented invention to the cost of developing the patented invention along with some percentage of profits. Thereby, if it costs $1 to create the patented invention you get to hold the patent until you earn $1 and the percentage of profits, which would happen really quickly (sell it one time); it it costs $1000 or $1,000,000 then you would hold it longer - e.g the market decides how long you get to hold it; outright sale of the patented invention to a third party would nullify the patent itself since you would have recouped the costs, and the prime motivator for patents is therefore enforced - that inventors be encouraged to invent new things - while equally destroying the troll market.
OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
Not quite. You can't repeat the pad the same way ever - that is, you don't want to wrap it or reset to known locations using any kind of protocol. You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap. So you're data limited unless you have an infinite data source.
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
LEDs are more expensive but they also have a higher potential lifespan than incandescent or CFL bulbs. They also have a lower power draw so unless we don't see the lifespan that they promise LEDs are probably a cheaper cost of ownership compared to incandescent bulbs.
True, supposedly so. I know I rarely changed an incandescent - probably once every couple years at most; I usually changed an incandescent because the bulb broke due to the lamp getting knocked over more than anything else - actually seeing the EOL of an incandescent was rare. I expect it will probably be the same with LEDs and CFLs; though LEDs will probably be because the electronics in their base die - capacitors drying out, etc; which will be a lot harder to test what is wrong with them.
They do have the higher capital cost, as you pointed out, but that means more that it prices them out of the range of lower income families who will be forced into the higher cost of ownership CFLs.
Which has the funny aspect of exposing those folk to mercury contamination...
Honestly, we shouldn't be trying to force the public to use one over the other. Let people choose free market style. There was no reason for the EPA to get involved in this. Would people still buy incandescents? Yes; but most would probably skip CFLs and go straight to LEDs as well - which were not really even part of the picture when Congress passed the bill mandating incandescents be phased out; and the phase out had little to nothing to do with the introduction of LEDs when they came.
Where are you buying 60 watt incandescents for 5-12 cents each? Or, a little more expensive (1.5 cents/bulb buying 2 at a time) but a better brand.
So a single LED bulb at a sale discount, versus 8 incandescent bulbs. FYI - average price of a single LED bulb is $7+ for 40/60/75/100W bulbs before any sale discounts.
Average prices for a 4 or 8 package of incandescent bulbs before any sale discounts was $2-3; I typically paid $1 for a 4 package at most.
Best price I've seen for CFLs was the occasional Sam's Club pack for $1 containing 8 CFLs (40/60/75/100W); but that's rare. Typically the same pack age Sam's Club is $8+.
And after our 4 yr old broke a CFL in his room (since we couldn't put a new Incandescent in), we replaced it with an LED, which I'd much prefer if not for the expense. Even then, the first one didn't work for some reason; fortunately the store did a return/exchange and the second one (a different brand) worked.
Well you would also benefit if you bought the newer, more efficient cars.
So what, exactly, is the problem here?
So here's the deal:
The list goes on.
Now I'm not saying that reducing emissions is not a good thing; or that reducing energy consumption is not a good thing - they are. However, when the cost of doing so ends up incurring an overall higher emissions rate, or more things to be toss out (thus increasing garbage and land-fills), etc...it's over impact is not worth the minor reduction in emissions.
Mod parent up!
The U.S. Could reciprocate and ban Intel exports.
One of Intel's major chip fabs is in China, so the chips can just be produced at that facility. Also, if the US bans exports, then it's likely that Intel would move existing US based chip fabs to Europe
That all depends on the type of ban.
For instance, a sale ban would still effect the company regardless of which of it's international subsidiary's did the actual sale.
A design ban would forbid them from designing in the US and exporting the design to facilities elsewhere to even produce chips matching the design.
There have been electric delivery trucks for a long time - for example, Smith Electric Vehicles has been making li-ion trucks almost as long as Tesla has been around. And they follow up on a long history of electric delivery vehicles on a continuous line dating back to the early lead-acid days. But "existing" doesn't mean "having blown the market wide open". The big question is when that could happen.
You know, though, as ridiculous as it sounds, I almost wonder Tesla's efforts could evolve into a killer delivery vehicle. The Model S / Model X drivetrain is already starting to get into the power range of a big rig, and big rig budgets can afford their high prices. Combine that this potential solution to charging over long distances and you really could have a winner.
So the primary issue for Big Rig trucking is distance.
Drivers often fill up 100-200 gallon tanks, and cover large distances between stops. They might stop for fuel once a day, may be twice while covering 500-1000 miles. Can we build a big rig that has the torque capacity AND the distance requirements? May be.
But then, you also need to be able to manage the batteries well enough too, and be able to recharge quickly.
Battery swapping won't really work. Why? Who owns the batteries? Who's responsible for them? What places are going to swap out batteries?
If the owner of the vehicle owns the batteries, then swapping doesn't work. Someone that just bought the batteries isn't going to swap them for a set of used batteries - that's too expensive.
A network of battery renters could work, but then you have to be able to get to one of their approved locations for a battery swap, so it's not really feasible, though this solution could bring the cost of the big rigs down considerably since they wouldn't have to buy the extremely expensive battery packs with the big rig, just sign up to a renter network.
Even then, who's responsible for batteries when there are problems? Who pays the bill when the battery overheats and blows up? Or who sends out another vehicle to swap batteries when the drain too quickly and the vehicle is stranded?
Yes, lawyers can solve many of the questions, but until that happens in a manner acceptable to the industry then there are problems.
Also, realize that many big rigs are owned by their drivers. Independent truckers are quite common and many trucking companies prefer to use independent truckers over buying their own equipment; often paying barely enough for the guys to be able to maintain the vehicles - it's a very cut throat business. So those buying the big rigs don't necessary have budgets for expensive technology; they just want something that is going to work, work well, be easy to maintain, and be highly reliable - it's very expensive for them to get a tow (loss work, plus the cost of tow and maintenance). So it'll be a very up-hill battle to get them to accept electric vehicles.
For truckers to accept electric trucks, companies will have to get into it first. So FedEx proving that this vendor is reliable with their fleet will go a long way to bringing hybrids to trucking at all levels.
As to the transition of the technology from trains - the really big difference is that for the trains it's generally easy for them to know exactly how much fuel they need for the trip and how much to have in reserve. The fuel tanks are in the thousands of gallons, and they don't have to deal with traffic much. When they do, they'll know how long the wait will generally be and can handle the situation accordingly. It's also relatively easy for them to just fill up the tanks again. Just saying - the two industries are extremely different in many respects; so what one finds acceptable won't necessarily be so for the other.
Randomly, the pump will display "please see register for receipt" upon selecting the print option. I've see it being random as the person after me (a friend), had his receipt print just fine. It's a fucking scam to lure people into the store and buy shit.
Why waste paper getting a receipt? Your credit card company has a record of the transaction.
Because if you need to dispute it saying "I always get my receipts and I don't have one for that" works really well. Otherwise, you're at the mercy of your bank/card company to accurate report what you are spending - not a good habit to be in.
And frankly, current ranges on EV's make them pretty much useless for trucks. Who really wants to stop for a couple hours a couple times a day?
You won't see pure EV trucks for a long time. What you'll see is a power train similar to that on locomotives. Diesel engine charging electric motors with a battery bank to deal with the excess. It's very efficient, huge torque and the technology is well understood. I'm kind of surprised we aren't seeing it already.
We're starting to, but not in the big rigs; FedEx was reportedly doing a test on their delivery vehicles with a start up from South Carolina at a cost of $100k/vehicle upgrade. A few more players in the market, and the cost will drop significantly.
what's to stop a Waffle House, IHOP, or similar just having a charging stations outside? I think these "gas" stations or any future derivatives are dead, especially if commercial or environmental regulations are lifted/ nonexistent for electric charging stations.
Nothing; it's actually a perfect business for hotels, restaurants and entertainment venues to get into - put chargers in the parking lots to encourage people to stop in, add a small portion to the bill if they use the charge. They'll very quickly replace the gas stations, which no one really wants to stop at or go inside of.
The one that I disagree with is 'Your source builds using something that isn't GNU Make [ +10 points of FAIL ]'. I disagree for two reasons. The first is that it implies using GNU make features, which likely means that you're conflating building and build configuration (which should gain some fail points). The projects that I most enjoy hacking on use CMake and Ninja for building by default (CMake can also emit POSIX Makefiles that GNU Make can use, but I take his point to mean that gmake is the only command you need to build, so the CMake dependency would be a problem). LLVM still more or less maintains two build systems, though the autoconf + gmake one is slowly being removed in favour of the CMake one. If I make a small change, it takes Ninja less time to rebuild it than it takes gmake to work out that it has nothing to do if I don't make any changes.
Agreed. Any cross-platform projects needs to be able to support multiple build systems, whether you like it or not. Tools like CMake/QMake/Qbs/Ninja/etc are just essential.
I'd also disagree with 'Your code doesn't have a changelog' - this is a GNU requirement, but one that dates back to before CVS was widely deployed. The revision control logs now fill the same requirement, though you should have something documenting large user-visible changes.
Agreed. You have version control. That's all you really need. ChangeLogs are generally outdated and for releases (where the VCS won't be available) a dump of the logs in some form should be sufficient, provided you are writing meaningful log messages. IOW, good VCS practices are a must.
"Christianity" in the US is nothing but a cult that rejects science, worships guns and war and is an anti-sex death cult.
Don't know which "christians" you know...but that's certainly not true.