Re:What he took away is more precious than given
on
Steve Jobs Dead At 56
·
· Score: 1
No, because it's not malware and it's been fixed. Just like this isn't malware, it's just plain stupidity and a malware scanner wouldn't have prevented either of these incidents from happening.
Re:What he took away is more precious than given
on
Steve Jobs Dead At 56
·
· Score: 1
The search was meant to indicate that it is widely accepted that there is malware for Android. Point me to one piece of malware for iOS that doesn't require a jailbroken device to work.
Re:What he took away is more precious than given
on
Steve Jobs Dead At 56
·
· Score: 2, Insightful
Walled gardens do us no favors.
I don't know about you, but I kind of like not having to worry about running malware scanners on my phone.
Adobe doesn't really care if you're using Flash or not. They've now created a set of native html5 development tools. As long as you're using Adobe software to author your content, they don't give a toss if you're using flash or not.
Flash served an important purpose in serving up multimedia content over the web, when there was no real other widely accepted solution. Now that browsers can natively handle just about everything that Flash could do as a plugin, whether or not it continues to be used isn't really the issue.
OpenFirmware - which is what PPC Macs used was a proprietary implementation of OpenBoot. The Extensible Firmware Interface is vaguely similar (ie, they're both a lot more powerful than a BIOS) but they don't really share many features other than that...
Re: UEFI only allowing signed bootloaders, my guess (and the sane thing to do) is to have a trusted path and an untrusted path in the bootloader.
If you boot from the trusted path with a signed bootloader, it will boot a signed OS and ensure a cryptographically safe boot process. This will then work with a signed bootloader and a signed OS and protect the OS from some kinds of rootkits.
If you boot from unsigned code, then it won't boot a signed OS - this will mean that an unsigned bootloader with a rootkit, won't be able to boot a signed OS like Windows 8. If you boot unsigned code, you can run an unsigned OS, such as Linux.
And witness the vendor lock-in imposed on you from the largest manufacturer on the planet of EFI powered machines. Notice how you can't boot any other OS on a Mac. Oh, hang on...
With the P6 onwards, Intel's x86 chips have been pretty well a RISC core wrapped with a powerful fetching and decoding engine that transforms "native" x86 instructions into CPU specific microcode. This decode engine makes some pretty good assumptions about being able to reorder instructions for greater throughput and the like, but it's got me wondering - would it be possible for the CPU's low-level microcode to be exposed as an instruction set and software compiled directly to the low-level RISC-like microcode?
Would this provide any tangible benefit to execution speeds (being able to skip part of the decode process) or would it allow a compiler to make more educated decisions about instruction reordering and general program flow if it had access to generate microcode instead of x86 instructions?
Would it be possible to have fat binaries that have x86 instructions and microcode instructions in the same file (fat binaries are possible on many systems, such as OS X where you can have PPC and x86 executable code in the one binary)
Why has this "finally backfired" - in what way was this an accident waiting to happen? What was it about the promo that leads the submitter to believe it was set up to fail from the start?
Scanning for most people is fraught with troubles, from too large files they cannot email, to losing files saved who knows where, to simple connection problems between scanner and computer.
I'll second that. I've got a relatively new MFC unit, print, fax, scan etc. The default setting when it scans is to do something like a 300dpi, 24-bit scan that makes something like a 15-25MB image for a single A4 page.
I immediately changed it down to something a lot more reasonable, 72dpi, 8-bit greyscale and the images are now jpeg compressed and weigh in at a couple of hundred k. They're more than clear enough to send to people and when printed are clearer than a fax.
Sensible default settings would help a lot here...
Generally email does not actually pass through a large number of servers between you sending it and someone receiving it. In a typical business environment where each entity runs their own mail server, your mail client will hand the message off to your mail server and this will probably be over a LAN. From there, your mail server looks up the MX record for the destination mail server and contacts it on port 25 (if you're really lucky, it might even chose to use smtps). It then streams the message off to the receiving mail server which will store it in the spool and hand it to the receiving user when they check their email.
What your email does pass through a large number of will be routers, but these aren't servers. It's true you can't guarantee the security of these routers however if one of them has been pwned, then it's going to be an ISP or a backbone carrier and chances are, whoever pwned these routers is after something a lot more valuable than your email.
Encrypted email is very straightforward to implement, at least on a Mac. I have my SMIME cert from a CA (let's not get into the reliability or otherwise of CAs at the moment, this is about email). When I send an email to you, it has an smime.p7s which is my public key. You can then import this into your keychain, or if you're on a Mac, the OS imports it into a keychain automatically. If you also have your certs set up, then you have enough information now to be able to email me securely - you've got my public key in a standard format so your mail client can use this to encrypt the mail you're sending, and only I'll be able to decrypt it, which happens transparently in my mail client.
Instead of hours and minutes, the mean solar day is divided up into 1000 parts called ".beats". Each.beat lasts 1 minute and 26.4 seconds. Times are notated as a 3-digit number out of 1000 after midnight. So, @248 would indicate a time 248.beats after midnight representing 248/1000 of a day, just over 5 hours and 57 minutes.
Judging from this info, you'll probably get away with 1 AP per floor located centrally and one for each courtyard and one for the lobby if you have high-gain antennas on the individual floor access points.
If you want to do this properly, it won't be cheap or easy. Companies like Cisco have some incredible products that will do exactly what you want, but you probably won't be able to configure them yourself.
You will probably need to run new cabling to the wireless access points, but if it's done properly this time, it'll be relatively future proof. Install one run of cat5e or cat6 cabling to each area where you need an access point, probably in a ceiling cavity or something like that. Install the access points, and power them via a Power over Ethernet switch (avoiding the need to run power cables to the access points too)
If you want to minimise the number of APs that you use, you can get some high-gain omnidirectional antennas for the APs to extend their coverage. If you've got a really tricky floorplan with lots of reinforced concrete walls, then you may need to go for more but lower powered access points.
Using the correct infrastructure from Cisco will provide all sorts of benefits - things like the APs being able to talk to each other over Ethernet and adjust their transmission power so they don't interfere with each other, being able to co-ordinate fast handovers from one AP to another so if you're, say, streaming media and move from one AP to another AP, the stream continues with no interruption.
You then want some kind of access solution - I've had great success with m0n0wall (http://m0n0.ch/) and this is the easy bit of the solution and something you will be able to manage yourself.
Yes, that's what probability and statistics are all about. The time quoted to break an encryption method generally is either worst case or worst case/2
One thing that really bit me in the arse with Zimbra (and the main reason I'll never use it again) is that all the decent information in their knowledgebase, and the info on what does and doesn't actually do was behind a login system that you could only access if you were already a customer.
There was one major bullet-point listed feature that simply didn't work. It was advertised as a feature on the website, but their bug tracker had outstanding bugs against it and it just did not work. Yet they still advertised it.
802.11a uses the (crowded) 2.4GHz range, as well as the (relatively unused) 5GHz range. Not a lot of consumer equipment supports 802.11a however (at least compared to 802.11g)
the 5GHz range is also used by 802.11n - which offers higher throughput than 802.11 a or g.
So much wifi equipment uses 2.4GHz that if you're getting too much interference here, if you switch to 802.11n and only broadcast your APs on 5GHz channels, you'll be amazed at how much better it is.
13 is allowed in Australia and Europe as well, but overlaps significantly with channel 11 and a few of the other higher channels. There is a channel 14 that is only allowed in Japan and it is far enough above even channel 13 that there's virtually no overlap. http://en.wikipedia.org/wiki/List_of_WLAN_channels
I just wish it was a little more user friendly. That was the one thing MySQL had going for it.. dead simple to use and admin.. and I imagine Apple's frontend probably made it even more so.
Apple didn't have a frontend to MySQL worth mentioning. In 10.6 Server and prior versions, there was a section for it in Server Admin with three settings. 1 Checkbox for "Allow network connections" – off by default. 1 Text entry box for "Database Location" – default/var/mysql 1 Button for "Set MySQL Root Password..."
There was also a tab in Server Admin where you could view the various log files and an Overview tab that tells you if it's running or not, the start time and if network connections are allowed.
And that was it. For the summary to imply that Apple had more than just command-line access to MySQL is a bit misleading. Sure, you can turn it on and off via the GUI, but you really can't configure much - you can't see or configure your users, tables or databases.
The remotes Sony used were fantastic. I can remember back in the mid 90's looking at my (relatively) bluky MZ-R50 and the slender tube of a remote and thinking aloud to my mates that "one day this remote you see here will be the media player itself". Now, they're even smaller than that.
The controls on the remote were fantastic as you say - one button on the very end and the twisting collar around it. Sony had a similar remote for car audio systems that would mount on the steering column too.
The remote is pretty simple in it's communication with the headunit - rather than anything fancy and digital, it used resistors of differing values to represent the different controls on the remote. You could even get a 24k resistor and short out the control pins on the headphone jack, toggle the hold switch on and off and you'd put the unit in service mode. The two useful things you could do in service mode were disable SCMS (until you power-cycle the unit or eject the current disc) and read the current temperature.
There was a lot less logic required to read the different resistor values than there would be for it to have a proper digital interface, you could probably interface it relatively easily with an Arduino or something similar these days...
...but also shoddy encoding and a high level of dynamic compression in iTunes.
What? iTunes AAC encoder is one of the best around and it's MP3 encoder, whilst not as flexible as LAME, stacks up very well. As for the dynamic compression, I don't know what you're talking about - iTunes doesn't do anything to the music in the way of eq or compression when it encodes it. There is an option to normalise tracks, but it's off by default and it's done at playback, it doesn't change the data on disk.
That all said, I've still gyt my MZ-R50 around which was one of the best MD walkmans ever made, especially with the tweak where you could short out the control pins on the headphone plug (the flat plug that the remote uses to communicate to the main unit next to the headphone jack) with a 24k resistor while toggling the hold switch and put it into service mode. Once in service mode, you could disable SCMS for the unit and record digital copies to your heart's content.
Exactly, the thing with a SAP rollout (or anything else of this magnitude) is that you pass the point of no return quite early into the project and then the consultants have you exactly where they want you - you can't go back now to your old system, but the new system doesn't really do what you expected it to either so as expensive as it seems, it's cheaper to keep paying more to fix the new system than it would be to migrate everything back to the old system...
Once it's all in place and working as it should, SAP can be a fantastic thing to have but getting there is _never_ as straightforward as one would be lead to believe initially.
Slashdot Mirror
No, because it's not malware and it's been fixed. Just like this isn't malware, it's just plain stupidity and a malware scanner wouldn't have prevented either of these incidents from happening.
The search was meant to indicate that it is widely accepted that there is malware for Android.
Point me to one piece of malware for iOS that doesn't require a jailbroken device to work.
Walled gardens do us no favors.
I don't know about you, but I kind of like not having to worry about running malware scanners on my phone.
Adobe doesn't really care if you're using Flash or not. They've now created a set of native html5 development tools. As long as you're using Adobe software to author your content, they don't give a toss if you're using flash or not.
Flash served an important purpose in serving up multimedia content over the web, when there was no real other widely accepted solution. Now that browsers can natively handle just about everything that Flash could do as a plugin, whether or not it continues to be used isn't really the issue.
OpenFirmware - which is what PPC Macs used was a proprietary implementation of OpenBoot.
The Extensible Firmware Interface is vaguely similar (ie, they're both a lot more powerful than a BIOS) but they don't really share many features other than that...
Re: UEFI only allowing signed bootloaders, my guess (and the sane thing to do) is to have a trusted path and an untrusted path in the bootloader.
If you boot from the trusted path with a signed bootloader, it will boot a signed OS and ensure a cryptographically safe boot process. This will then work with a signed bootloader and a signed OS and protect the OS from some kinds of rootkits.
If you boot from unsigned code, then it won't boot a signed OS - this will mean that an unsigned bootloader with a rootkit, won't be able to boot a signed OS like Windows 8. If you boot unsigned code, you can run an unsigned OS, such as Linux.
And witness the vendor lock-in imposed on you from the largest manufacturer on the planet of EFI powered machines. Notice how you can't boot any other OS on a Mac. Oh, hang on...
With the P6 onwards, Intel's x86 chips have been pretty well a RISC core wrapped with a powerful fetching and decoding engine that transforms "native" x86 instructions into CPU specific microcode. This decode engine makes some pretty good assumptions about being able to reorder instructions for greater throughput and the like, but it's got me wondering - would it be possible for the CPU's low-level microcode to be exposed as an instruction set and software compiled directly to the low-level RISC-like microcode?
Would this provide any tangible benefit to execution speeds (being able to skip part of the decode process) or would it allow a compiler to make more educated decisions about instruction reordering and general program flow if it had access to generate microcode instead of x86 instructions?
Would it be possible to have fat binaries that have x86 instructions and microcode instructions in the same file (fat binaries are possible on many systems, such as OS X where you can have PPC and x86 executable code in the one binary)
Why has this "finally backfired" - in what way was this an accident waiting to happen? What was it about the promo that leads the submitter to believe it was set up to fail from the start?
Scanning for most people is fraught with troubles, from too large files they cannot email, to losing files saved who knows where, to simple connection problems between scanner and computer.
I'll second that. I've got a relatively new MFC unit, print, fax, scan etc. The default setting when it scans is to do something like a 300dpi, 24-bit scan that makes something like a 15-25MB image for a single A4 page.
I immediately changed it down to something a lot more reasonable, 72dpi, 8-bit greyscale and the images are now jpeg compressed and weigh in at a couple of hundred k. They're more than clear enough to send to people and when printed are clearer than a fax.
Sensible default settings would help a lot here...
Generally email does not actually pass through a large number of servers between you sending it and someone receiving it.
In a typical business environment where each entity runs their own mail server, your mail client will hand the message off to your mail server and this will probably be over a LAN. From there, your mail server looks up the MX record for the destination mail server and contacts it on port 25 (if you're really lucky, it might even chose to use smtps). It then streams the message off to the receiving mail server which will store it in the spool and hand it to the receiving user when they check their email.
What your email does pass through a large number of will be routers, but these aren't servers. It's true you can't guarantee the security of these routers however if one of them has been pwned, then it's going to be an ISP or a backbone carrier and chances are, whoever pwned these routers is after something a lot more valuable than your email.
Encrypted email is very straightforward to implement, at least on a Mac. I have my SMIME cert from a CA (let's not get into the reliability or otherwise of CAs at the moment, this is about email). When I send an email to you, it has an smime.p7s which is my public key. You can then import this into your keychain, or if you're on a Mac, the OS imports it into a keychain automatically. If you also have your certs set up, then you have enough information now to be able to email me securely - you've got my public key in a standard format so your mail client can use this to encrypt the mail you're sending, and only I'll be able to decrypt it, which happens transparently in my mail client.
You mean like teh bittorrents
Why not ditch the 24 hour day as well.
http://en.wikipedia.org/wiki/Swatch_Internet_Time
Why? Because it doesn't work.
Judging from this info, you'll probably get away with 1 AP per floor located centrally and one for each courtyard and one for the lobby if you have high-gain antennas on the individual floor access points.
If you want to do this properly, it won't be cheap or easy.
Companies like Cisco have some incredible products that will do exactly what you want, but you probably won't be able to configure them yourself.
You will probably need to run new cabling to the wireless access points, but if it's done properly this time, it'll be relatively future proof.
Install one run of cat5e or cat6 cabling to each area where you need an access point, probably in a ceiling cavity or something like that. Install the access points, and power them via a Power over Ethernet switch (avoiding the need to run power cables to the access points too)
If you want to minimise the number of APs that you use, you can get some high-gain omnidirectional antennas for the APs to extend their coverage. If you've got a really tricky floorplan with lots of reinforced concrete walls, then you may need to go for more but lower powered access points.
Using the correct infrastructure from Cisco will provide all sorts of benefits - things like the APs being able to talk to each other over Ethernet and adjust their transmission power so they don't interfere with each other, being able to co-ordinate fast handovers from one AP to another so if you're, say, streaming media and move from one AP to another AP, the stream continues with no interruption.
You then want some kind of access solution - I've had great success with m0n0wall (http://m0n0.ch/) and this is the easy bit of the solution and something you will be able to manage yourself.
Yes, that's what probability and statistics are all about. The time quoted to break an encryption method generally is either worst case or worst case/2
One thing that really bit me in the arse with Zimbra (and the main reason I'll never use it again) is that all the decent information in their knowledgebase, and the info on what does and doesn't actually do was behind a login system that you could only access if you were already a customer.
There was one major bullet-point listed feature that simply didn't work. It was advertised as a feature on the website, but their bug tracker had outstanding bugs against it and it just did not work. Yet they still advertised it.
Yes, mod it. Because this is not only legal, but trivial to do as well... Oh, hang on a minute, no it's not.
What will be the easiest (and legal) way to do it is to use wireless n on the 5GHz band which will be far less crowded than 2.4GHz.
802.11a uses the (crowded) 2.4GHz range, as well as the (relatively unused) 5GHz range. Not a lot of consumer equipment supports 802.11a however (at least compared to 802.11g)
the 5GHz range is also used by 802.11n - which offers higher throughput than 802.11 a or g.
So much wifi equipment uses 2.4GHz that if you're getting too much interference here, if you switch to 802.11n and only broadcast your APs on 5GHz channels, you'll be amazed at how much better it is.
13 is allowed in Australia and Europe as well, but overlaps significantly with channel 11 and a few of the other higher channels.
There is a channel 14 that is only allowed in Japan and it is far enough above even channel 13 that there's virtually no overlap.
http://en.wikipedia.org/wiki/List_of_WLAN_channels
I just wish it was a little more user friendly. That was the one thing MySQL had going for it.. dead simple to use and admin.. and I imagine Apple's frontend probably made it even more so.
Apple didn't have a frontend to MySQL worth mentioning. In 10.6 Server and prior versions, there was a section for it in Server Admin with three settings. /var/mysql
1 Checkbox for "Allow network connections" – off by default.
1 Text entry box for "Database Location" – default
1 Button for "Set MySQL Root Password..."
There was also a tab in Server Admin where you could view the various log files and an Overview tab that tells you if it's running or not, the start time and if network connections are allowed.
And that was it. For the summary to imply that Apple had more than just command-line access to MySQL is a bit misleading. Sure, you can turn it on and off via the GUI, but you really can't configure much - you can't see or configure your users, tables or databases.
You mean you were able to get support from someone at facebook?
The remotes Sony used were fantastic. I can remember back in the mid 90's looking at my (relatively) bluky MZ-R50 and the slender tube of a remote and thinking aloud to my mates that "one day this remote you see here will be the media player itself". Now, they're even smaller than that.
The controls on the remote were fantastic as you say - one button on the very end and the twisting collar around it. Sony had a similar remote for car audio systems that would mount on the steering column too.
The remote is pretty simple in it's communication with the headunit - rather than anything fancy and digital, it used resistors of differing values to represent the different controls on the remote. You could even get a 24k resistor and short out the control pins on the headphone jack, toggle the hold switch on and off and you'd put the unit in service mode. The two useful things you could do in service mode were disable SCMS (until you power-cycle the unit or eject the current disc) and read the current temperature.
There was a lot less logic required to read the different resistor values than there would be for it to have a proper digital interface, you could probably interface it relatively easily with an Arduino or something similar these days...
UMD wasnt a terrible idea, it was that Sony never let us make burn our own discs. Name one popular media format that DOESNT have recordable media.
Vinyl.
...but also shoddy encoding and a high level of dynamic compression in iTunes.
What? iTunes AAC encoder is one of the best around and it's MP3 encoder, whilst not as flexible as LAME, stacks up very well. As for the dynamic compression, I don't know what you're talking about - iTunes doesn't do anything to the music in the way of eq or compression when it encodes it. There is an option to normalise tracks, but it's off by default and it's done at playback, it doesn't change the data on disk.
That all said, I've still gyt my MZ-R50 around which was one of the best MD walkmans ever made, especially with the tweak where you could short out the control pins on the headphone plug (the flat plug that the remote uses to communicate to the main unit next to the headphone jack) with a 24k resistor while toggling the hold switch and put it into service mode. Once in service mode, you could disable SCMS for the unit and record digital copies to your heart's content.
Exactly, the thing with a SAP rollout (or anything else of this magnitude) is that you pass the point of no return quite early into the project and then the consultants have you exactly where they want you - you can't go back now to your old system, but the new system doesn't really do what you expected it to either so as expensive as it seems, it's cheaper to keep paying more to fix the new system than it would be to migrate everything back to the old system...
Once it's all in place and working as it should, SAP can be a fantastic thing to have but getting there is _never_ as straightforward as one would be lead to believe initially.