Yes, at least partially. I think the most important component is that you'll only get application resources (like graphics, but potentially others depending on the application) that are required for the device you have. This means you'll not get graphics that aren't even targeted for your device, which is easy and a good thing, because you'll not have resources for retina screens on non-retina devices or vice versa. It basically rips out stuff you'll never need on your specific target device. And as far as I understand it this is not Apple doing magic, but the app developer defining in XCode which resources are targeted at which type of device.
DIsclaimer: I'm not a mobile app developer, I just watched the presentation and demo showing the XCode screens for defining this:)
Why don't we try the open source route and have people adopt these at-risk core system utilities? Won't there be any interest if those are up for adoption? If we get 3-4 volunteers per tool we can for sure do something about this and get more people to contribute to those tools.
Any ideas on what might be a suitable replacement for Pipes? As it so happens I'm lazy and still seem to be using one or two pipes we built a long time ago:)
Indeed; I just looked this up several days ago and I'd be very carful with the Series 30+ phones that Microsoft Mobile is currently releasing. Although they're cheap and nice for a second phone, they're priced appropriately for what they are, which is not much in terms of even basic dumbphone features.
The Nokia 301 and the Nokia 515 are probably the "last" good dumbphones out there, and they're available as single and dual-sim... all the others either have problems with the address book sync, are not at least triband, or have some weird issues with connecting to in-car systems with bluetooth (although that last point was only my impression after reading reviews on the web, but not car manufacturer is testing dumbphones anymore:-/)
The mistake he made was not understanding the tools he was using. Apparently neither do you.
(1) The key could have been scraped at any time once it was pushed, because you can't actually "delete[d] all traces from GitHub" (some ways are more thorough than others, but nothing is foolproof with Google wandering the earth). He needed to revoke his keys immediately.
You do realize that you actually can modify a git repository to delete all traces of a file you previously comitted, don't you? If not, check out http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
I'm not sure I can help out with the project itself as I don't know what it is and what it is written in, but I've been recently working on static site generators and if it helps I might be able to help you migrate it over and hosting it on s3, github, or a privately owned server, depending on what is the best fit going forward.
I guess in the security advisory there will be a neat list of affected companies. This is already a good first step to get this funding and process issue addressed... it's just a matter of someone taking it from there. But I'm not holding my breath.
From my reading this actually does not only track bills, but automatically settles the payment transaction. I guess even the banks don't do this (yet). Paypal or local banks might be a prime candidate for something like this, though. Notwithstanding any prior art I guess this should be obvious to not only people in IT, but also to people in banking;-)
google glass doesn't keep an always on buffer going on all the time. it records after you activate recording somehow. it is not like a dashcam in that sense. in that way it works like a smartphone or whatever camera.
btw, security cameras are illegal in austria?
No, security cameras are not illegal as long as you're only recording private property. As soon as you record on public property the recording needs to be registered with the data privacy commission and you need a reason for doing this. (e.g. perimeter cameras outside of bank buildings and such)
Nice that you made that available under the Apache License and that you're allowed to integrate contributions! It would be nice to have a great Python IDE available as open source. I'll definitely check this out when I get a chance!
And over here in Austria we have not developed anything and our banks just send letters with one-time-passwords to every customer and let them enter it into a standard web page that even works in firefox on any operating system.:-)
Although this will probably change with the introduction of the digital signatures, but up until now... nothing happened because there is not really a driver for people to switch to digital signatures where you suddenly need a smart card reader.
Usually with today's drivers and performance requirements it's pretty hard to pass user credentials through to the backends because it breaks your connection pool logic most of the time as you can not share connections anymore.
Actually the reason why you're "sharing" backend application-accounts in Middleware is because the drivers that allow access to the databases usually don't permit you to change the authorization information without tearing down the connections and connecting all over again, which breaks the whole idea of connection pools and severely hurts performance.
The burst rates don't matter because they're not sustained rates and even the unsustained rates are highly unlikely because the HDD is actually very dumb about it's content and has no idea what or why you just requested some tracks/blocks. - Most of the time it won't be of any use. Even in write caching, because transfer rates drop substantially as soon as the cache is full or you try to read additional data.
It is correct though that burst rates have some limited impact on performance of the HDD but for the usage of a non-tech savy person and even for the home-use of tech savy persons it is just plain useless.
But you could still have people login as root with their own private keys and still know who logged in when. - Apart from that you never have much accountability if you can su anyway.
But there is not a better way on unix because the only way that would provide more accountability would be to use sudo with restrictive commands and log every access down to the command executed.
And this is why? Because we never had exploits in ssh? well... my memory might be bad... but not that bad...
Come one guys. - This is the same service as ssh. remote access. It's just remote desktop because windows users always need to point-and-click... but it's the same service and it's used to do the same thing.
Why do you assume that it is even necessary to lower labor costs? - I'd be very interested if you can point me to any documentation that would state exactly why this is necessary.
Not only that, but you're actually causing MAJOR disruptions in the current company if you let a large number of people go in certain locations.
I mean the people that worked for a company previously surely didn't just come in to get a coffee each day and run around in the office to keep the others from working.
The disruptions also happen in customer contact because the customers suddenly have to go and call someone in India instead of in Europe. - Which is usually not what customers want, but so what?
I'm not sure this will work out for any of these companies, but I hope the disruptions won't be too big that they lose too many talented people, because that would really sad. But maybe they find a better job than they had at their old company and help build the next google. who knows what it's good for?
You know... Change doesn't have to be bad... but that doesn't help if you were pink slipped.
Actually it makes me very angry to read this over and over again in articles about unions in Europe vs the US. - I have to say that I really like the european system much better than the US system in most ways.
The main problem is that you assume that these are jobs that can be performed anywhere. I think that I don't want this job anyway if it can be duplicated easily somewhere else.
I like to believe that we're adding value to a business with our work and this includes our geographical and cultural insight that we bring to the table when we meet with the customers in Europe. - If this is not the case, just bring in someone from India for a telco or buy them an airline ticket.
What you completely missed is the point that this seems to happen in the US _and_ Europe, so it can't really be something that is specific to any one of these two systems, right?
I guess we'll have to look for the things that are actually common and find the problem there.
I was actually thinking the other way around. - The bluetooth would have the bluetooth logic and terminate the call from the cellphone directly into your headphones.
That way you have hi-fi sound while also getting your phone calls and everything would be integrated.
Slashdot Mirror
Yes, at least partially. I think the most important component is that you'll only get application resources (like graphics, but potentially others depending on the application) that are required for the device you have. This means you'll not get graphics that aren't even targeted for your device, which is easy and a good thing, because you'll not have resources for retina screens on non-retina devices or vice versa. It basically rips out stuff you'll never need on your specific target device. And as far as I understand it this is not Apple doing magic, but the app developer defining in XCode which resources are targeted at which type of device.
DIsclaimer: I'm not a mobile app developer, I just watched the presentation and demo showing the XCode screens for defining this :)
Why don't we try the open source route and have people adopt these at-risk core system utilities? Won't there be any interest if those are up for adoption? If we get 3-4 volunteers per tool we can for sure do something about this and get more people to contribute to those tools.
I would definitely be up for something like that.
Any ideas on what might be a suitable replacement for Pipes? As it so happens I'm lazy and still seem to be using one or two pipes we built a long time ago :)
Indeed; I just looked this up several days ago and I'd be very carful with the Series 30+ phones that Microsoft Mobile is currently releasing. Although they're cheap and nice for a second phone, they're priced appropriately for what they are, which is not much in terms of even basic dumbphone features.
The Nokia 301 and the Nokia 515 are probably the "last" good dumbphones out there, and they're available as single and dual-sim... all the others either have problems with the address book sync, are not at least triband, or have some weird issues with connecting to in-car systems with bluetooth (although that last point was only my impression after reading reviews on the web, but not car manufacturer is testing dumbphones anymore :-/)
The mistake he made was not understanding the tools he was using. Apparently neither do you.
(1) The key could have been scraped at any time once it was pushed, because you can't actually "delete[d] all traces from GitHub" (some ways are more thorough than others, but nothing is foolproof with Google wandering the earth). He needed to revoke his keys immediately.
You do realize that you actually can modify a git repository to delete all traces of a file you previously comitted, don't you? If not, check out http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
I'm not sure I can help out with the project itself as I don't know what it is and what it is written in, but I've been recently working on static site generators and if it helps I might be able to help you migrate it over and hosting it on s3, github, or a privately owned server, depending on what is the best fit going forward.
I guess in the security advisory there will be a neat list of affected companies. This is already a good first step to get this funding and process issue addressed... it's just a matter of someone taking it from there. But I'm not holding my breath.
From my reading this actually does not only track bills, but automatically settles the payment transaction. I guess even the banks don't do this (yet). Paypal or local banks might be a prime candidate for something like this, though. Notwithstanding any prior art I guess this should be obvious to not only people in IT, but also to people in banking ;-)
google glass doesn't keep an always on buffer going on all the time. it records after you activate recording somehow. it is not like a dashcam in that sense. in that way it works like a smartphone or whatever camera.
btw, security cameras are illegal in austria?
No, security cameras are not illegal as long as you're only recording private property. As soon as you record on public property the recording needs to be registered with the data privacy commission and you need a reason for doing this. (e.g. perimeter cameras outside of bank buildings and such)
Nice that you made that available under the Apache License and that you're allowed to integrate contributions! It would be nice to have a great Python IDE available as open source. I'll definitely check this out when I get a chance!
And over here in Austria we have not developed anything and our banks just send letters with one-time-passwords to every customer and let them enter it into a standard web page that even works in firefox on any operating system. :-)
Although this will probably change with the introduction of the digital signatures, but up until now... nothing happened because there is not really a driver for people to switch to digital signatures where you suddenly need a smart card reader.
Usually with today's drivers and performance requirements it's pretty hard to pass user credentials through to the backends because it breaks your connection pool logic most of the time as you can not share connections anymore.
Actually the reason why you're "sharing" backend application-accounts in Middleware is because the drivers that allow access to the databases usually don't permit you to change the authorization information without tearing down the connections and connecting all over again, which breaks the whole idea of connection pools and severely hurts performance.
I guess grand-parent actually knew what he was doing.
Under the US VWP old passports issued before the cut-off date on 10/26/05 just need to be machine-readable and have no further requirements.
So if you got your passport before that date you can still enter the US as long as your passport is valid.
The burst rates don't matter because they're not sustained rates and even the unsustained rates are highly unlikely because the HDD is actually very dumb about it's content and has no idea what or why you just requested some tracks/blocks. - Most of the time it won't be of any use. Even in write caching, because transfer rates drop substantially as soon as the cache is full or you try to read additional data.
It is correct though that burst rates have some limited impact on performance of the HDD but for the usage of a non-tech savy person and even for the home-use of tech savy persons it is just plain useless.
So I basically have to link this from here, maybe people will learn eventually.
7
This whole mess is just not funny anymore.
http://www.kuro5hin.org/story/2002/11/10/122820/9
Which is exactly the way it should be even with the servers that now run zOS, Solaris, AIX, Linux, or even Windows. wait... it actually IS that way :-)
Why should anyone let programmers mess up a production system again?
But you could still have people login as root with their own private keys and still know who logged in when. - Apart from that you never have much accountability if you can su anyway.
But there is not a better way on unix because the only way that would provide more accountability would be to use sudo with restrictive commands and log every access down to the command executed.
But maybe I'm missing something.
And this is why? Because we never had exploits in ssh? well... my memory might be bad... but not that bad...
Come one guys. - This is the same service as ssh. remote access. It's just remote desktop because windows users always need to point-and-click... but it's the same service and it's used to do the same thing.
Get over it.
Why do you assume that it is even necessary to lower labor costs? - I'd be very interested if you can point me to any documentation that would state exactly why this is necessary.
Well... the MBAs are much cheaper in India anyway... And the food is healthier too... *g*
Not only that, but you're actually causing MAJOR disruptions in the current company if you let a large number of people go in certain locations.
I mean the people that worked for a company previously surely didn't just come in to get a coffee each day and run around in the office to keep the others from working.
The disruptions also happen in customer contact because the customers suddenly have to go and call someone in India instead of in Europe. - Which is usually not what customers want, but so what?
I'm not sure this will work out for any of these companies, but I hope the disruptions won't be too big that they lose too many talented people, because that would really sad. But maybe they find a better job than they had at their old company and help build the next google. who knows what it's good for?
You know... Change doesn't have to be bad... but that doesn't help if you were pink slipped.
Actually it makes me very angry to read this over and over again in articles about unions in Europe vs the US. - I have to say that I really like the european system much better than the US system in most ways.
The main problem is that you assume that these are jobs that can be performed anywhere. I think that I don't want this job anyway if it can be duplicated easily somewhere else.
I like to believe that we're adding value to a business with our work and this includes our geographical and cultural insight that we bring to the table when we meet with the customers in Europe. - If this is not the case, just bring in someone from India for a telco or buy them an airline ticket.
What you completely missed is the point that this seems to happen in the US _and_ Europe, so it can't really be something that is specific to any one of these two systems, right?
I guess we'll have to look for the things that are actually common and find the problem there.
just my 2 euro cents.
I was actually thinking the other way around. - The bluetooth would have the bluetooth logic and terminate the call from the cellphone directly into your headphones.
That way you have hi-fi sound while also getting your phone calls and everything would be integrated.
That way you could accept calls from your cell while listening to music on the iPod without taking out the phone and switching off the iPod.
:-)
Why did nobody in Cupertino have that idea?