Why is it that the "global" rankings are nearly identical to those of North America. It's clear that the sampling is fubar.
Re:Example of a REALLY SIMPLE Plone site?
on
Two Books On Plone
·
· Score: 1
Most people don't need the bells and whistles of plone. Unfortunately the stock CMF skins are _ugly_ (which is why plone was started). It took me ~2 days to write a decent set of skins for CMF. The experience gave me a much better understanding of how Zope, CMF and plone work.
Re:Plone is an overdesigned piece of crap
on
Two Books On Plone
·
· Score: 1
If you actually _dive in_ to the CMF framework (the Zope product which plone is built upon), you'll discover that plone is a CMF "skin" on steroids.
It would be far more accurate to complain about CMF than plone itself.
It's a PIC (go google).. the vendor is obviously programming it for this particular application. Only the vendor would know how generic/specific their code is.
In a perfect world, we'd encrypt end to end. Welcome to the real world...
Would you rather a user use SSL for everything they do? You want to push security up to top layers.. this seems incredibly more complex to maintain than providing security @ L1 thru L3. I'm sorry but far too many companies utilize applications that do not provide encryption at the application layer.
I welcome the technology. I'm sick of running all my apps over ssh tunnel while on wireless link.
I don't really understand the design choices made by the author..
Why solid state? You have to put the audio data somewhere... It's certainly not going to fit on the CF.
Who cares about HD "chatter"/RF when you have a mobo emitting all the RF you could ever want? A/D conversion should be done outside of the PC so that RF is a non-issue.
Not knowing what THX-1138 was, first glance of the article title resulted in the reply: "Sonofa! I have to upgrade my home theater for *another* audio format!?"
You're correct in that a speed test is not going to try to make any assumptions about TCP/IP overhead because it's likely the apps have no idea as to what client MTU is. To set things straight, IP header is usually 20 bytes without options. TCP another 20 bytes without options. So at least 40 bytes of overhead for every packet.
If you consider someone subject to a low MTU.. say 576, every packet consists of ~ 7% overhead. Compare this with ethernet @ ~ 2.6%. To make matters worse, you have to deal with more downstream ACKs, etc. In short, header overhead *does* impact throughput.
MIDI itself is not capable of producing any sound. MIDI is only a means of controlling a synthesizer. Real time synthesis can be very CPU intensive. With this device, you could feed something like Reaktor (a very versatile synth package for the PC) with the keyboard (midi controller).
The purpose of this device is to provide musicians with a midi PC solution for real time synth, etc. It's nice not having to lug around a PC and a midi controller.
I've been considering a client/server solution which places a low power (fanless) client PC near your home theater. This client would do things like announce incoming calls (vgetty), news, etc. The client would also be able to serve audio and possibly video content from the server.
Anyway.. for this to work effectively, I'd need a means to overlay graphics on the existing video signal to my TV/monitor. Does anyone know of an inexpensive means of doing this? Maintaining video quality is key. Many audio receivers do this w/ volume display, input selection, etc.
The only devices I've found that do this are "overlay/genlock" devices and cost hundreds of dollars.
To prevent sounding biased... I run FreeBSD on all servers. I ran Linux on my laptop until FreeBSD 5.1 was released. I switched because I use FreeBSD more often, not because Linux was lacking. I run XP on my workstation. I'm quite familiar with the strenths and weaknesses of each platform.
Back on topic...
5.2RC2 was released what?.. less than one week ago? I don't think you invested enough time to make an educated decision.
If you were a long time Windows/MacOS user, and gave Linux/BSD/Solaris/WTFE a few hours of your time, do you honestly think you would switch? I very much doubt it.
"Why did I spend an hour of my time installing THIS!?"
In short, changing OSes requires a fair amount of tenacity. A true geek cannot be a zealot. You've got blinders on my friend. Open your eyes and you will see how great *BSD really is.
BSD's focus on the desktop has been of a far lower priority than that of Linux'. Sorry, but I don't need USB, sound, an office package, or the ability to play games on my servers.
Conway's book is the best I've read on the subject of perl OOP. If you take the time to make sure you *understand* each and every concept and mechanism, the book will leave you with a firm understanding of objects. This shouldn't be a problem as the book is a delightful read. A firm understanding of the perl language, references, globs, packages, etc would be an important requisite as the book is not for the novice.
Re: #2 I'm pretty sure this is in place to keep kiddies from using scripts which use random spoofed IPs for attacks.
As stated many times, preventing your gateway from decrementing is a poor solution. It's best to change the default TTL across all hosts (make sure they're the same.. 142 is a good number!).
IINM, sequence numbers could be rewritten by the gateway to prevent overlapping. Giving each connection (or host) a SN "domain" to work within and maintaining a SN offset (ie client SN + offset = gateway SN) would make this fairly trivial. Working out an algo to calculate efficient domain sizes based upon the # of hosts/average # of connections would be the most difficult part. Too big and you'll run out of domains.. too small and you'll kill large xfers.
Eh.. you're not going to make the TTL disappear. Changing the TTL at the gateway (ie. don't decrement, or set to new value) violates RFC and will break certain diagnostic tools.
The best solution is to change the default TTL on hosts behind the gateway.
If the device has any interest in TCP state, it would ignore the FIN unless the usual SYN+ACK, ACK sequence followed the client's initial SYN. Most SYN proxies (what I would classify this device as) watch initial state quite closely, so I doubt such an "attack" would prove useful.
Spoofed IPs are not a problem since you cannot easily ACK the server's SYN (since you'll never see it, thus no way to know ISN).
JetDirect devices support LPD.. so I'd expect that this "appliance" does as well. I was also a bit confused about this article. Linux (and any unix that can run LPD) *is* supported AFAIK. Commercial support may be an issue though.
Slashdot Mirror
VG Keramidas (you typo'ed his name in post) has his name on all kinds of academic research papers... google away.
Why is it that the "global" rankings are nearly identical to those of North America. It's clear that the sampling is fubar.
Most people don't need the bells and whistles of plone. Unfortunately the stock CMF skins are _ugly_ (which is why plone was started). It took me ~2 days to write a decent set of skins for CMF. The experience gave me a much better understanding of how Zope, CMF and plone work.
If you actually _dive in_ to the CMF framework (the Zope product which plone is built upon), you'll discover that plone is a CMF "skin" on steroids.
It would be far more accurate to complain about CMF than plone itself.
You radical! RIAA will have you killed!
It's a PIC (go google).. the vendor is obviously programming it for this particular application. Only the vendor would know how generic/specific their code is.
In a perfect world, we'd encrypt end to end. Welcome to the real world...
Would you rather a user use SSL for everything they do? You want to push security up to top layers.. this seems incredibly more complex to maintain than providing security @ L1 thru L3. I'm sorry but far too many companies utilize applications that do not provide encryption at the application layer.
I welcome the technology. I'm sick of running all my apps over ssh tunnel while on wireless link.
I don't really understand the design choices made by the author..
Why solid state? You have to put the audio data somewhere... It's certainly not going to fit on the CF.
Who cares about HD "chatter"/RF when you have a mobo emitting all the RF you could ever want? A/D conversion should be done outside of the PC so that RF is a non-issue.
Not knowing what THX-1138 was, first glance of the article title resulted in the reply: "Sonofa! I have to upgrade my home theater for *another* audio format!?"
Yes.. 60% overhead is bullshit.
You're correct in that a speed test is not going to try to make any assumptions about TCP/IP overhead because it's likely the apps have no idea as to what client MTU is. To set things straight, IP header is usually 20 bytes without options. TCP another 20 bytes without options. So at least 40 bytes of overhead for every packet.
If you consider someone subject to a low MTU.. say 576, every packet consists of ~ 7% overhead. Compare this with ethernet @ ~ 2.6%. To make matters worse, you have to deal with more downstream ACKs, etc. In short, header overhead *does* impact throughput.
Try writing a 400 page manual with PageMaker. FrameMaker fills its purpose well.
MIDI itself is not capable of producing any sound. MIDI is only a means of controlling a synthesizer. Real time synthesis can be very CPU intensive. With this device, you could feed something like Reaktor (a very versatile synth package for the PC) with the keyboard (midi controller).
The purpose of this device is to provide musicians with a midi PC solution for real time synth, etc. It's nice not having to lug around a PC and a midi controller.
I've been considering a client/server solution which places a low power (fanless) client PC near your home theater. This client would do things like announce incoming calls (vgetty), news, etc. The client would also be able to serve audio and possibly video content from the server.
Anyway.. for this to work effectively, I'd need a means to overlay graphics on the existing video signal to my TV/monitor. Does anyone know of an inexpensive means of doing this? Maintaining video quality is key. Many audio receivers do this w/ volume display, input selection, etc.
The only devices I've found that do this are "overlay/genlock" devices and cost hundreds of dollars.
TIA
To prevent sounding biased... I run FreeBSD on all servers. I ran Linux on my laptop until FreeBSD 5.1 was released. I switched because I use FreeBSD more often, not because Linux was lacking. I run XP on my workstation. I'm quite familiar with the strenths and weaknesses of each platform.
Back on topic...
5.2RC2 was released what?.. less than one week ago? I don't think you invested enough time to make an educated decision.
If you were a long time Windows/MacOS user, and gave Linux/BSD/Solaris/WTFE a few hours of your time, do you honestly think you would switch? I very much doubt it.
"Why did I spend an hour of my time installing THIS!?"
In short, changing OSes requires a fair amount of tenacity. A true geek cannot be a zealot. You've got blinders on my friend. Open your eyes and you will see how great *BSD really is.
BSD's focus on the desktop has been of a far lower priority than that of Linux'. Sorry, but I don't need USB, sound, an office package, or the ability to play games on my servers.
Nokia IPSO is based upon FreeBSD 2.2.6.
Conway's book is the best I've read on the subject of perl OOP. If you take the time to make sure you *understand* each and every concept and mechanism, the book will leave you with a firm understanding of objects. This shouldn't be a problem as the book is a delightful read. A firm understanding of the perl language, references, globs, packages, etc would be an important requisite as the book is not for the novice.
It sucks to have a unique last name when tools like Google exist.
Re: #2
I'm pretty sure this is in place to keep kiddies from using scripts which use random spoofed IPs for attacks.
As stated many times, preventing your gateway from decrementing is a poor solution. It's best to change the default TTL across all hosts (make sure they're the same.. 142 is a good number!).
IINM, sequence numbers could be rewritten by the gateway to prevent overlapping. Giving each connection (or host) a SN "domain" to work within and maintaining a SN offset (ie client SN + offset = gateway SN) would make this fairly trivial. Working out an algo to calculate efficient domain sizes based upon the # of hosts/average # of connections would be the most difficult part. Too big and you'll run out of domains.. too small and you'll kill large xfers.
Eh.. you're not going to make the TTL disappear. Changing the TTL at the gateway (ie. don't decrement, or set to new value) violates RFC and will break certain diagnostic tools.
The best solution is to change the default TTL on hosts behind the gateway.
If the device has any interest in TCP state, it would ignore the FIN unless the usual SYN+ACK, ACK sequence followed the client's initial SYN. Most SYN proxies (what I would classify this device as) watch initial state quite closely, so I doubt such an "attack" would prove useful.
Spoofed IPs are not a problem since you cannot easily ACK the server's SYN (since you'll never see it, thus no way to know ISN).
They got jailed for *FRAUD* not for spamming.
JetDirect devices support LPD.. so I'd expect that this "appliance" does as well. I was also a bit confused about this article. Linux (and any unix that can run LPD) *is* supported AFAIK. Commercial support may be an issue though.