This article could be interesting if it included references to who said what and in which context. Just saying "[[tech]] is a toy." without further developing or even including at least a reference is pointless - one could come up with just about any tech as an example whenever real or not.
This article is unfortunately nothing more than a waste of time:(
That thing - coLinux - was the best thing I've ever used in terms of Linux over Windows... I was really sad they couldn't get it running on 64bit hardware.
On a serious note though, I won't shed a tear for CryptoRush.in. Using the same password on a small, no-reputation mining pool as the admin access to a currency exchange!?! That's a huge fail even by the lowest security standards, and these guys should know better.
Then what about getting coins stolen from the hot wallet and not even flagging the loss? What's even the point of an offline wallet when you don't reconcile the hot wallet before adding funds to it?? Another huge neglect on their part.
I actually it's probably a good thing they're now out of business because with that level of laxity, if not now there's no doubt it would have happened later, likely with more users and bigger balances... It's just sad for those who lost their coins in the process.
So they figured they always end up botching every other release, so why not throw away Windows 9 before development even started and go straight to Windows 10?
Indeed - from experience an average computer with standard GPU will do between 2 and 20 Mhash/s (not all GPUs will be usable, and most computers around with usable GPUs will have low-end ones). The best GPU's will make a whooping 600 to 900 Mhash/s, and even with that it'll be pretty hard to compete against the ASIC rigs - there's already devices making 60 Ghash/s (60,000 Mhash/s), and the upcoming rigs will do up to 1,500 Ghash/s (that's 1,500,000 Mhash/s!). In a few months the network difficulty will be so high even the best GPU's won't earn anything from mining....
They might make a little bit of cash now if they can infect a lot of computers, but it won't last for long...
One thing that would be awesome is a 64bit coLinux port!
coLinux is a win32 application with drivers that lets you run a Linux kernel with userspace natively in Windows - it is much lighter than any virtualisation option out there, and using Xming you can easily run GUI apps that launch and run just as well as if they were natively ported to windows.
Unfortunately the drivers were never ported to 64-bit, and thus is it now useless on all but the oldest computers out there. A 64-bit coLinux port would be a requirement to getting this awesome project back on its rails.
And also andLinux - which offered an easy way to install and configure coLinux - think of it like coLinux being the Linux kernel and andLinux the Linux distribution... http://www.andlinux.org/
I would love to be able to use coLinux again on my work PC, which (unfortunately) has to run Windows.
I did pretty much that to install a linux distro on a 486 laptop - I compiled the kernel, libraries, etc. - then built a bootdisk and filesystem. I then went on and copied the ~15m filesystem using a bunch of floppies (no network) one disk at a time after booting from the floppy, and finally installed the bootloader.
The Linux From Scratch HOWTO has all instructions for it, although in my case I diverted a little bit from it - for instance I used uClibc instead of Glibc and a 2.2 kernel. Doing it from scratch gives you the best way to select more recent components for some parts while using smaller/older ones elsewhere, so you don't end up with a totally outdated system.
Actually the problem isn't with browsers, but rather some Web servers that see a difference between "example.com" and "example.com." IIS is one of them, which makes the "issue" quite visible.
This is a very generic model; do you have any idea who manufactured the board inside? It appears most other WinCE laptops out here are based on that exact same board - the shell/color differs but the ports are placed exactly at the same place!
If one of them runs Linux that would likely be a good starting point, then you need to figure out a way to write the flash memory.
Yes, actually the CRTC imposed Bell to apply this to its own customer first. The way I understand it:
A. Bell customers:
Customer uses much bandwidth. Bell pays for internet bandwidth and gets paid by customer.
B. Wholesale service:
Customer uses much bandwidth. ISP pays for internet bandwidth AND pays Bell for usage, then ISP gets paid by customer.
Despite the fact that *everyone else* involved in the process were against this, the CRTC agreed mostly because it was claimed there's the same practices in Cable wholesale. The difference, though, is that DSL is dedicated access, and once the infrastructure is paid for (trough the base fee) there is nearly no costs to additional bandwidth besides the Internet bandwidth which is already paid by the ISP. Cable, on the other hand, is a shared medium with limited bandwidth, and the more customers use ut, the more has to be spent on upgrading the infrastructure to prevent congestion on the cable segments.
This scheme will hurt small ISPs which will have to impose limits, while it will allow Bell to make more profits and possibly cut its own prices at the same time.
It doesn't seems like anyone here gets it. This is for wholesale services, not Bell's own customers.
Long story short: Bell has the lines because it had telephone monopoly, so it must loan its lines to other DSL ISPs for a fair price. DSL ISPs can therefore use Bell lines to give customers access, but in the end data goes to the ISP's network and they're the one paying for actual bandwidth costs.
This has led to a few ISPs like Teksavvy and AEI who sell unlimited bandwidth DSL trough cheap upstream networks like Cogent (actually Teksavvy offers both: limited good bandwidth of unlimited cheap one).
Now, what bell is doing is that in addition to the fair infrastructure fees, they added usage costs. Note that the "usage" isn't costing much to bell because data travels only between the subscribers (DSLAMs) and the ISP whish is all within Bell's own network; they don't have to pay any upstream provider. On the other hand, ISPs will pay twice the bandwidth usage: they will have to pay over-usage to Bell, plus the actual upstream costs. For all of us who choose 3rd party ISPs to avoid extra bandwidth costs, we'll end up paying over-usage just like if we used Bell, and this is why people call this unfair usage costs to cut competition.
Making Linux a microkernel wouldn't help much, except maybe you wouldn't have to recompile the kernel to change the feature set. Besides, microkernels tend to be slower. Due to their architecture some things can't be done directly but rather have to be "communicated" to the right component. The communication channel often become a bottleneck.
I somewhat agree with Linus, the kernel is bloated. Many other things are bloated as well in many distributions. For that reason, on servers I manage I use Slackware (Which is a very slim and customizable OS) with hand-selected packages and custom-compiled kernels. It is obviously much harder to get advanced things done in Slackware but I gain a lot in resources usage and stability.
And this is what I like most about Linux and open source in general. If you don't like it you can customize it. Linux makes a particularly good job at it by letting you decide in great details what you want compiled in and what you don't. I can tell by the time it compiles that my server kernels are incredibly smaller than most generic kernels out there. In addition, Slackware is a god trade-off between usability and simplicity (I could use Gentoo to get exactly what I want but I loose on the usability side). It is very lean yet it can do most of the job out of the box, and for the more advanced things I compile my own custom packages or install from source.
You don't need uniprocessor, just run one instance per CPU. You may also have workers processes (ex php workers) and poll them. either way you can achieve full CPU usage without using threads.
Threads can be an advantage in multi-processor systems but I haven't seen that many applications implementing them properly. Having too many threads running at the same time wastes more time in context switches, OTOH one process per CPU using epoll in a non-blocking event loop is very simple to do and gives you excellent scalability.
As far as I know, besides primes there's a bunch of random data that gets in key generation. Knowing the primes only make it slightly easier to crack the key.
By default PGP use a known set of primes to generate keys, and so far keys generated by it are still secure.
I believe the probability being halved has something to do with the birthday paradox. It's been a time where I could explain this better; if you wish to find out just search for it on Google... This page seems to have a good explanation too:
Ok, it's getting a bit off-topic, but up-scaling is the most hilarious feature I ever saw on electronics devices. It doesn't make the picture any better and TVs should support lower resolutions just as well (mine does).
Arguably, even more laughable are up-scaling recorders, as it takes more bits for the same quality, but the quality isn't any better after scaling it up either!
AFAIK BD still have a small penetration and most people are still using standard DVD's (I even recall an article a couple weeks ago about avericans having more HD-DVD players in circulation than BD players!)
Just wait until more people use DB and I'm sure it won't be long before each new BD+ gets cracked promptly...
The author of this article seems totally clueless about what "beaming broadband via satellite" means, as it has absolutely nothing to to with 3G or anything cellular related. Cell phones require widespread wireless installation to cover a given area and just couldn't be done remotely!
Broadband internet can work via satellite using a dish antenna, just like with any satellite TV. It has a high latency (~500 ms in each direction AFAIK, so if you're not using terrestrial lines for outbound traffic that means ~1000 ms) but could definitely be used for that purpose.
Why the hell would you want to use VM's? It add complexity and overhead. It doesn't even take into account that a database (preferably a redundant one) will likely be required.
A much simpler setup: get heartbeat running between two servers, set up each server to run a web server with floating IP, do the same with MySQL (one master, one slave, configured so that they can both live on the same server) and configure DNS round-robin between the two floating web IPs.
You can probably add LVS on top of that if you wish (still managed with heartbeat) - I don't have too much experience with LVS though.
As you grow, you can add more servers to handle the load and eventually separate the DB and WEB clusters.
Not quite. The "root key" will sign the root zone, and all the delegations for the TLDs (.com,.org,.ca,.uk,.gov, etc.)
The TLDs will then sign anything below them. So the.com key will sign the delegation to google.com, and the.org key will sign the delegation to slashdot.org.
It will be then be up to each organization to sign their own records, and possibly delegate any sub-domains.
Basically it's one large set up of PGP key-sign and webs of trust.
True. I've been a bit mislead... There's still a whole lot of domains that will be signed by network solutions though.
While DNSCurve sounds interesting (like a lot of Bernstein's stuff), besides his software, what uses it?
Actually his software does not even implement this yet (I guess he's looking to see if it gets traction from the rest of the world first). Besides, I read on an IETF list about people who independently wrote a client and server implementations. It is simpler to implement than DNSSEC in many aspects too.
Slashdot Mirror
This article could be interesting if it included references to who said what and in which context. Just saying "[[tech]] is a toy." without further developing or even including at least a reference is pointless - one could come up with just about any tech as an example whenever real or not.
This article is unfortunately nothing more than a waste of time :(
That thing - coLinux - was the best thing I've ever used in terms of Linux over Windows... I was really sad they couldn't get it running on 64bit hardware.
Just to days short and CNBC would have make fool of itself on April Fool's day! ;)
After researcher on Valve, season is starting early this year.
I have a problem! somebody all my fleshcoins! the whole thing!
Well that sounds like the solution to http://xkcd.com/792/ 's problems...
On a serious note though, I won't shed a tear for CryptoRush.in. Using the same password on a small, no-reputation mining pool as the admin access to a currency exchange!?! That's a huge fail even by the lowest security standards, and these guys should know better.
Then what about getting coins stolen from the hot wallet and not even flagging the loss? What's even the point of an offline wallet when you don't reconcile the hot wallet before adding funds to it?? Another huge neglect on their part.
I actually it's probably a good thing they're now out of business because with that level of laxity, if not now there's no doubt it would have happened later, likely with more users and bigger balances... It's just sad for those who lost their coins in the process.
So they figured they always end up botching every other release, so why not throw away Windows 9 before development even started and go straight to Windows 10?
Indeed - from experience an average computer with standard GPU will do between 2 and 20 Mhash/s (not all GPUs will be usable, and most computers around with usable GPUs will have low-end ones). The best GPU's will make a whooping 600 to 900 Mhash/s, and even with that it'll be pretty hard to compete against the ASIC rigs - there's already devices making 60 Ghash/s (60,000 Mhash/s), and the upcoming rigs will do up to 1,500 Ghash/s (that's 1,500,000 Mhash/s!). In a few months the network difficulty will be so high even the best GPU's won't earn anything from mining....
They might make a little bit of cash now if they can infect a lot of computers, but it won't last for long...
One thing that would be awesome is a 64bit coLinux port!
coLinux is a win32 application with drivers that lets you run a Linux kernel with userspace natively in Windows - it is much lighter than any virtualisation option out there, and using Xming you can easily run GUI apps that launch and run just as well as if they were natively ported to windows.
Unfortunately the drivers were never ported to 64-bit, and thus is it now useless on all but the oldest computers out there. A 64-bit coLinux port would be a requirement to getting this awesome project back on its rails.
See:
http://www.colinux.org/
http://colinux.wikia.com/wiki/Dashboard_for_developing_a_64_bit_coLinux
And also andLinux - which offered an easy way to install and configure coLinux - think of it like coLinux being the Linux kernel and andLinux the Linux distribution...
http://www.andlinux.org/
I would love to be able to use coLinux again on my work PC, which (unfortunately) has to run Windows.
I did pretty much that to install a linux distro on a 486 laptop - I compiled the kernel, libraries, etc. - then built a bootdisk and filesystem. I then went on and copied the ~15m filesystem using a bunch of floppies (no network) one disk at a time after booting from the floppy, and finally installed the bootloader.
The Linux From Scratch HOWTO has all instructions for it, although in my case I diverted a little bit from it - for instance I used uClibc instead of Glibc and a 2.2 kernel. Doing it from scratch gives you the best way to select more recent components for some parts while using smaller/older ones elsewhere, so you don't end up with a totally outdated system.
It wouldn't be if they actually had invented the CDN. They's unfortunately about 12 years late...
Actually the problem isn't with browsers, but rather some Web servers that see a difference between "example.com" and "example.com." IIS is one of them, which makes the "issue" quite visible.
Only because they've been so idiot to run the kiosk as an administrator!
With its default permissions, HKLM cannot be altered by normal users, and I don't see why a kiosk would need any additional privileges.
This is a very generic model; do you have any idea who manufactured the board inside? It appears most other WinCE laptops out here are based on that exact same board - the shell/color differs but the ports are placed exactly at the same place!
If one of them runs Linux that would likely be a good starting point, then you need to figure out a way to write the flash memory.
Yes, actually the CRTC imposed Bell to apply this to its own customer first. The way I understand it:
A. Bell customers:
Customer uses much bandwidth. Bell pays for internet bandwidth and gets paid by customer.
B. Wholesale service:
Customer uses much bandwidth. ISP pays for internet bandwidth AND pays Bell for usage, then ISP gets paid by customer.
Despite the fact that *everyone else* involved in the process were against this, the CRTC agreed mostly because it was claimed there's the same practices in Cable wholesale. The difference, though, is that DSL is dedicated access, and once the infrastructure is paid for (trough the base fee) there is nearly no costs to additional bandwidth besides the Internet bandwidth which is already paid by the ISP. Cable, on the other hand, is a shared medium with limited bandwidth, and the more customers use ut, the more has to be spent on upgrading the infrastructure to prevent congestion on the cable segments.
This scheme will hurt small ISPs which will have to impose limits, while it will allow Bell to make more profits and possibly cut its own prices at the same time.
It doesn't seems like anyone here gets it. This is for wholesale services, not Bell's own customers.
Long story short: Bell has the lines because it had telephone monopoly, so it must loan its lines to other DSL ISPs for a fair price. DSL ISPs can therefore use Bell lines to give customers access, but in the end data goes to the ISP's network and they're the one paying for actual bandwidth costs.
This has led to a few ISPs like Teksavvy and AEI who sell unlimited bandwidth DSL trough cheap upstream networks like Cogent (actually Teksavvy offers both: limited good bandwidth of unlimited cheap one).
Now, what bell is doing is that in addition to the fair infrastructure fees, they added usage costs. Note that the "usage" isn't costing much to bell because data travels only between the subscribers (DSLAMs) and the ISP whish is all within Bell's own network; they don't have to pay any upstream provider. On the other hand, ISPs will pay twice the bandwidth usage: they will have to pay over-usage to Bell, plus the actual upstream costs. For all of us who choose 3rd party ISPs to avoid extra bandwidth costs, we'll end up paying over-usage just like if we used Bell, and this is why people call this unfair usage costs to cut competition.
Making Linux a microkernel wouldn't help much, except maybe you wouldn't have to recompile the kernel to change the feature set. Besides, microkernels tend to be slower. Due to their architecture some things can't be done directly but rather have to be "communicated" to the right component. The communication channel often become a bottleneck.
I somewhat agree with Linus, the kernel is bloated. Many other things are bloated as well in many distributions. For that reason, on servers I manage I use Slackware (Which is a very slim and customizable OS) with hand-selected packages and custom-compiled kernels. It is obviously much harder to get advanced things done in Slackware but I gain a lot in resources usage and stability.
And this is what I like most about Linux and open source in general. If you don't like it you can customize it. Linux makes a particularly good job at it by letting you decide in great details what you want compiled in and what you don't. I can tell by the time it compiles that my server kernels are incredibly smaller than most generic kernels out there. In addition, Slackware is a god trade-off between usability and simplicity (I could use Gentoo to get exactly what I want but I loose on the usability side). It is very lean yet it can do most of the job out of the box, and for the more advanced things I compile my own custom packages or install from source.
You don't need uniprocessor, just run one instance per CPU. You may also have workers processes (ex php workers) and poll them. either way you can achieve full CPU usage without using threads.
Threads can be an advantage in multi-processor systems but I haven't seen that many applications implementing them properly. Having too many threads running at the same time wastes more time in context switches, OTOH one process per CPU using epoll in a non-blocking event loop is very simple to do and gives you excellent scalability.
As far as I know, besides primes there's a bunch of random data that gets in key generation. Knowing the primes only make it slightly easier to crack the key.
By default PGP use a known set of primes to generate keys, and so far keys generated by it are still secure.
I believe the probability being halved has something to do with the birthday paradox. It's been a time where I could explain this better; if you wish to find out just search for it on Google... This page seems to have a good explanation too:
http://betterexplained.com/articles/understanding-the-birthday-paradox/
Ok, it's getting a bit off-topic, but up-scaling is the most hilarious feature I ever saw on electronics devices. It doesn't make the picture any better and TVs should support lower resolutions just as well (mine does).
Arguably, even more laughable are up-scaling recorders, as it takes more bits for the same quality, but the quality isn't any better after scaling it up either!
AFAIK BD still have a small penetration and most people are still using standard DVD's (I even recall an article a couple weeks ago about avericans having more HD-DVD players in circulation than BD players!)
Just wait until more people use DB and I'm sure it won't be long before each new BD+ gets cracked promptly...
The author of this article seems totally clueless about what "beaming broadband via satellite" means, as it has absolutely nothing to to with 3G or anything cellular related. Cell phones require widespread wireless installation to cover a given area and just couldn't be done remotely!
Broadband internet can work via satellite using a dish antenna, just like with any satellite TV. It has a high latency (~500 ms in each direction AFAIK, so if you're not using terrestrial lines for outbound traffic that means ~1000 ms) but could definitely be used for that purpose.
Some GNU humour (couldn't paste it - Slashdot filters don't like GNU humour)...
http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/etc/JOKES?revision=1.4&root=emacs
Why the hell would you want to use VM's? It add complexity and overhead. It doesn't even take into account that a database (preferably a redundant one) will likely be required.
A much simpler setup: get heartbeat running between two servers, set up each server to run a web server with floating IP, do the same with MySQL (one master, one slave, configured so that they can both live on the same server) and configure DNS round-robin between the two floating web IPs.
You can probably add LVS on top of that if you wish (still managed with heartbeat) - I don't have too much experience with LVS though.
As you grow, you can add more servers to handle the load and eventually separate the DB and WEB clusters.
Not quite. The "root key" will sign the root zone, and all the delegations for the TLDs (.com, .org, .ca, .uk, .gov, etc.)
The TLDs will then sign anything below them. So the .com key will sign the delegation to google.com, and the .org key will sign the delegation to slashdot.org.
It will be then be up to each organization to sign their own records, and possibly delegate any sub-domains.
Basically it's one large set up of PGP key-sign and webs of trust.
True. I've been a bit mislead... There's still a whole lot of domains that will be signed by network solutions though.
While DNSCurve sounds interesting (like a lot of Bernstein's stuff), besides his software, what uses it?
Actually his software does not even implement this yet (I guess he's looking to see if it gets traction from the rest of the world first). Besides, I read on an IETF list about people who independently wrote a client and server implementations. It is simpler to implement than DNSSEC in many aspects too.