not at all, just playing my post so you could continue further if you wanted. Sometimes a good gag just needs a straight man to continue, guess your's didn't. Would a gay one have been better?
And no, most of the Lampoon stuff was from before my time. The little I've found and read were not enough to cause flashbacks. Now, if I had only been on proper 70's medication, maybe the flashbacks would be more vivid.
Just because the router's log says 'DoS' doesn't mean it is a DoS. The timestamps are the giveaway. A real DoS would look like:
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
Notice how all of the time stamps are the same (i got lazy and copy/pasted. they would also be different ports and hosts in a DDoS but still the same second)? You'd have the log on any home router filled each second if you were being hit with 16 Mbps of ACK scans. Every time you loaded the next page, it would be a different, newer time stamp because the log overflowed. An ACK scan is just another computer punching your IP address into the browser window and asking 'hey, is anyone at this address and port?" (effectively) And yeah, lots of those bots do check common ports like 80 to see if you report back that you have a webserver that they might be able to hijack. And amazon cloud services have made spawning lots of bots pretty easy. But those are scans that are few and far between, and your router spent less than 1ms deciding to chuck each of those packets. And, and ACK packet is generally tiny, next to no bandwidth usage. So think how many other packets could breeze through in the other 999ms of a given second (something like 15.9 Mbps, I think) that a single ACK came at you.
The problem with one device running wireshark and other devices all connected to a router is that, by virtue of IP, the wireshark running box won't see the traffic sent to the other PCs. You need to either set up a good Knoppix or Kali Linux boot disc device to act as a pass through, or get a cheap hub, or learn about ARP poisoning to get the traffic to first go to the monitoring box, then get passed along to the target device.
Ideally, Your network would be a very simple DSL modem, not a modem+router. Just a modem or your router reconfigured to bridge mode. Then a hub, yeah, the dumb collision prone boxes are very useful still. Uplink of the hub goes to the modem, and your sniffing box and a good NAT+firewall router get connected to it. Then, behind that NAT and firewall goes your computer. Against, ideally, the sniffing computer will not have requested an IP address, will not even have put it's ethernet port into anything but a passive state. Then you can start up wireshark. After that, start up your machine you think is attracting the attacks. You can sort wireshark traffic by incoming and outbound. And if changing the externally visible IP hasn't helped, you want to look at outbound to see what you are sending to who to get yourself noticed.
I have done exactly this, and it isn't fun or easy, but it did help pass a few Cisco network tests later. Once you get into packet sniffing, and ARP poisoning switches, and packet manipulation of those ARP poisoned packets, you can do all kinds of interesting things. Upsidedownternet doesn't have to be a proxy, it can be done with any switched network if done right. And then, after you graduate from wired networks to sniffing on wireless (and collecting large logs to break keys, or doing deauth attacks on your own gear to see how your modem+router and PC stand up) then you can start in on a whole world of fun and crazy bit-level cleverness.
disclaimer: I've cracked WEP back in the PCMCIA days of having a high speed 802.11b card (custom firmware to go into monitor mode) but it was on my own network or with permission (parents wanted to know how long it would take for a neighbor to borrow their wifi, I remember leaving the linux box running about an hour and a half, but sibling had lots of traffic going). WPA deauth attacks are the same way, don't screw with other people without permission. But once you have permission, go wild; showing my younger sibling their AIM chats when they thought 'the network is encrypted, you can't see me' was a hilarious way to spend my first summer home from college.
The modem side won't have an IP or MAC, it's a layer 1 device, but since it's a DSL router (layer 3 is for routers, you know, IP layer?) it will have both. You know, so the computer can chat with the router at x.x.x.1 or be routed to the other devices in the network by IP? If you have a combined device, and don't have enough access to it's controls to change it's MAC, then get it into a simple Modem mode (sometimes called bridge mode) and hook up a single router that you do control as the first step in the network and feed all traffic through that router. This will, as a consequence of being a simple modem now, make only one of the ethernet ports active and probably/hopefully turn off it's wifi if it has a radio. Then, you really can change your MAC on your router and just hit refresh to get a brand new IP from the ISP.
Now, one thing that hasn't been covered is whether all the traffic is at one port, or across a range or at random. That I noticed, I showed up late to the thread. If your ISP is giving you a NAT address (192.168.x.x or 10.x.x.x or a few others), and you have gotten one port at their outside linked to a certain port inside your network (steaming, gaming, etc) then a DDOS against your ISP could spill over to you every time someone outside tosses packets at the port you are attempting to use.
Lastly, a simple traceroute is still a useful tool. If you get to your ISP's network boarder without very large latency or packet loss, then the problem might be completely external to your network and just leaking in as described above. If you can't even get a ping to the first router beyond your modem, then the OP is being targeted. How? See the other posts.
If you are going to troll in a biology thread, at least go back to the roots of the phrase for the abbreviation? Latin "Panem et circenses" PAeCR1 would at least look like a real gene or protein pathway. Maybe a neuron condition that causes blind following of those one agrees with? But...oh gods, that would mean you would be expressing that gene too!
I wish we could get rid of this idiotic idea of XX=female, XY = male. Gender and sex are NOT even close to that simple.
It would be nice if people could understand that. Or at least understand that XY genotypes can be born expressing a female phenotype, and vice versa; but getting the general populace to believe anything that goes against what they were taught in school is very tough to do. "If it's that complicated, why don't they teach that?" I've actually heard that, as if a high school advance placement A&P or an on level biology course could get through all of that in less than one term. Sure, it makes Punnett squares easy to understand and relate to personal knowledge, but it's so far from right that it needs to just be tossed out of high school classes completely. "23X0, XXY, XYY, AIS, Turner's Syndrome, and lots of other combinations just make teaching simple 2 gene human expression too difficult. There are so many possible mutations of the genes involved, too many ways for multiple genes to combine like discussed about Down's Syndrome, and too many external genes that also influence human sex and gender (and expression of both and sexuality as well) for it to ever be discussed in the simplified manner needed at the high school level."
Unfortunately, even spelling it out in mostly small words like that doesn't often work. Even getting them to understand that X and Y were picked not because of the shape of the chromosome, which all look like an X during mitosis, but because they were common 'unknowns' in math. When biologists need a new set, they continued with W and Z. "Wiki doesn't say that," results in my face meeting the nearest wall repeatedly, because a facepalm just isn't a strong enough reaction.
Ever seen the Humble Indie Bundles, where GNU/Linux users tend to buy closed source games? I have FTL installed on my A/V workstation, just for those bits of 'brain frozen, working must stop for a few minutes' and it runs just fine. Not exactly an open source game; you might take a look at the Steam library of all the closed source Linux games they support now.
Before the game needs patched? If the game is making calls to OpenGL, then the game doesn't care how the window manager/desktop or the X11/X.org/Wayland/etc handle those calls as long as the version of OpenGL is supported. The only issue will come down to how kernel updates are managed. Too many people punch their package manager for every update, then whine when the bleeding edge kernel isn't supported by the closed-source binary driver for their bleeding-edge graphics card. This is either a problem in the distribution (pushing kernel updates without full support) or the user (updating the kernel without the right binaries available) depending on how you want to look at it. Or to save space, they update a library with a rapidly changing API to the newest version every time a release comes along, and then file bug reports everywhere. If the library isn't stable, then the game devs should force dependency on a certain release, or static link it. And if the user wants to uninstall the library when the game says 'hey, I depend on that' and the package manager allows it? That's back to a distro problem. So it seems like the real problems are average users using bleeding-edge distributions, or stupidly uninstalling things they shouldn't. Hey, I wonder what would happen if I went and uninstalled all those DX patches in SysWOW folders, think everything will still run right afterwards?
Frankly, stabilizing a set of "these files will be available to all games if the OS level is at least at patch version X.Y.Z" seems to be what SteamOS is aiming at. Which would let users do exactly what you say the average users want to be able to do.
As for using Qt on an embedded system, I didn't think you were serious about it. But I've met people who don't look at the specs and think that any library should compile right and do what it's told on any target architecture. So a master of Qt might have a hard time getting the underlying stuff (like the OS, the graphics driver, X.org!) going before moving on to actually running. Worse, think that since their target is an AVR, gcc-avr will be able to tell what syscalls are needed to talk to the other connected devices.
I don't mean to bring down anyone who works at that high level, UI stuff is beyond me for the most part. But it's great fun to sit down with a compiler and write some simple C99 targeting both the ARM9 and ARM7 codes of a Nintendo DS. The homebrew world is pretty good about getting very simple libraries that just do one target thing, but gluing a bunch together isn't always all that good either. Specific to the DS, in 2 screen mode the ARM7 is the chip that has to talk to the audio chip, the ARM9 can just send it signals on what it wants done, while the 7 has to get coded to do that. So a demo might use the 9 to do most of the work, and call a playNote(freq, duration,...) that the 7 runs and passes to the audio. But if you don't know the wireing, and try to run your audio straight from the 9, nothing works. If you write all your code in the 9 and then pass each individual unstruction as setDACfreq(freq) and setDACduration(duration) and then play(), you've just locked the 9 and the 7 cores up for 3 function calls instead of 1, and the available cycles to draw, compute AI and game engine stuff, will be delayed for 3 times as long. The first take the 9 one function, the 7 a single response and passing that along to the audio chip (inline function? or a simple movement of all music the the 7's memory and the 9 just sending a playNow(songArrayName) that doesn't wait for a return, and then both can do back to doing other parts of the demo, while the 7 waits for the timer interrupt to say 'next note now'. And the graphics calls on that system . . . sheesh! The early libraries were mostly text and interface reads.
To do that at the high level only, without going into the lower details, requires a big library that might not exist on your target yet. So a new coder can wait, and the good coder can at least piece together a hacked up library while they wait for the great embedded gods to create a really good library or OS. Personally, I'm not that patient to go through all the spec sheets and testing bus lines, but am comfortable piecing together a hacked up library to do what I need to get done. I'm not going to write the first 'print text to screen' library, but from that and someone else doing the probing and explaining it in simple detail (this chip uses syscall2 to do...) I can cobble together what I need to get my projects underway. I know, that requires a library of sorts to get those syscalls out to the programmer and the compiler to have the right target abilities; all the levels above that is where I'm comfortable with my code. But that knowledge of the caveats and gotchas that pop up and are usually in the original documentation from the folks doing that first gcc port, and knowing how to apply what those docs mean when they reference the buses and chip capabilities and flaws is an important skill. Something that many "glue together libraries and other peoples demo code" coders I know don't do. They tend to be so agnostic to the hardware that I've seen (C++ time now) a pointer set by a call to new() that wasn't in the initializer of the class but in a private function called when the object appears in view (and doesn't check that it wasn't already initialized) and then also failed to check that new returned a non-null value before dereferencing it. And finally ends with delete() in the destructor and finishes with setting the pointers to 0 (architecture dependency again, 0 isn't always null, and it isn't always memory location 0x0 either, but it was in the destructor
VHDL is . . . writing a document to generate a circuit board, IMO. Really, you should be able to take most VHDL that use common components (4xxx CMOS or 74xx TTL) and get the output as a schematic. It may be that FPGA and other VHDL-targets are cheaper and more well stocked with the obsurca of devices (DAC, ADC, timer and PLL timer mux or dividers, and so on) than a cabnet full of hard epoxy ang glass and copper IC components, but a bus is just a wire on a breadboard or a trace on a circuit board. Granted, the VHDL to schematic won't add and do the routing to get equal length traces (without compiler support, I would expect), or place the needed chokes and caps to maintain a good power supply or audio (no VHDL targets I've used required me to think about those parts), or know which diode to use to drop anything over 0.8v to 0.6 (audio 1v to -1v AC for audio distortion) but you could hook up with a parts library and get all the parts you'd need.
I suppose thinking like a VHDL writer does make doing shaders easier, since it's all parallel operations. But shaders are image processing for the most part. Or obfuscating a problem to look like image processing (assuming you aren't using shaders as part of OpenCL or something and your code is actually the normal code just compiled into shader functions...the compiler and library doing to obfuscating for you). Going the other way, from shaders to VHDL, you'd still need to know the hardware parts and how to make your code do very simple steps. Or maybe that's Verilog, I get the two syntaxes confused all the time.
Since the article was about useful ideas, I think knowing a simple assembly language is still a good thing to pick up. It doesn't have to run in anything other than an emulator that even allows for non-standard instructions like 'print out what's in register X' so you can tinker. C doesn't expose all the flaws that show up at the embedded level, because the compiler can hide them away behind the base libraries. The transistor level I leave for computer engineers instead of programmers; it's useful to know about pipelines, and if you are doing embedded programming you need to know how many instructions deep and how the jump prediction works, but you don't need to worry about the electron propagation like the engineers do.
And I disagree that all programming is being done at a high level now. Look at the way people build modchips for consoles, break HDCP encryption, and even the console designers who have to put together the OS and all the embedded programmers who are adding drivers for graphics chip X or radio chip Y to the latest Android/Windows/iOS device. They are programmers, the banking DBA who throws together a system where your account balance is a floating point and chucks that to a webpage isn't - in my book. You could be a good programmer without understanding things below the JRE, or you might not be. It'd be hard to tell, and it would vary so wildly from the coder who just knows how to glue together other libraries without checking that the functions returned a non-error value to the one who understand enough to know what's going on below the JRE level but just hasn't learned it yet.
A good compiler, as pointed out elsewhere in this discussion (look for lisp and closures) can be implemented in very few steps for the right language, and still be complete and usable.
You mean like Heapsort? One of those algos that most computer science programs still require you to write, just to prove you understand how to implement a heap?
Teaching the concept doesn't have to be the same as 'just teach the concept', You can do a puzzle with recursion, like Towers of Hanoi. Start them with a physical model, then keep adding rings. Let a kid figure out how adding a new ring increases the number of steps to solve it much faster than the ring before did. Ta-da, recursion and Big-O complexity, without actually bringing up either one. If the kid gets interested enough to grab a book on programming, then some of the basic stuff is already grounded in a real concept and they'll have a better understanding of it. Then again, I had a great computer teacher from 4th grade through 7th who taught like that on some shiny new Apple ][ and an occasional C64. Asked her years later why she taught us like that, and how it had helped me jump ahead in college. It was because she didn't know how to program at all, the computers were a gift to the school, and so she just gave us puzzles that could be solved without a computer and that it amazed her how kids could pick up the technology to solve the problems. Apple Basic was easy enough to read, and she forced comments and writing it on paper first, so she could see that we understood the problem and weren't just throwing random things until something worked.
Bonus to the Towers problem: does where you put the smallest ring determine where the final tower will be? How, and why?
That being said, if you master every aspect of Qt5 including QML and using network and databases, and development for different mobile devices, while also embracing the functional aspect of JavaScript (for QML and HTML), you should be pretty well set for everything on every platform;-)
Except embedded systems with multiple parallel data buses between different architecture chips, like an average handheld game device or a phone. You could flounder, trying to get Qt5 to run on it or any other library of your choice when the OS hasn't been finished yet. But you'd probably end up with something that barely runs and at a pace that makes snails stop and feel pity. And sometimes building those libraries from scratch is the job, and if you are used to using something as big at Qt to handle stuff for you, you might not be able to manage the tasks that it obfuscates.
Knowing how the CPU works can be a big help. I've seen coders who don't know how a floating point value or operation take place; which leads to them not knowing why adding 1,234,567,891,011.12 to 0.01 can end up different if you reverse the order of the values. It leads to not knowing why 127+1 rolls over to -0 instead of -1 on certain architecture. And it leads to not knowing why a pointer works, even if the pointer is abstracted behind a language that is effectively interpreted into C before being compiled to object code. Or what jobs the compiler and linker are actually doing, should the language of choice require them.
And with so much effort going into embedded systems, you can write your code in what ever high level language you choose, but you better understand the underlying architecture. And learning something simple (MIPS 1 or the Acorn RISC machine ARM2), and early, can let you pick up the harder stuff later while understanding the concepts that you just couldn't manage without.
Also, once you understand databases conceptually, everything starts to look like a special case of a database. This is a good thing. C data structures? Table records. Pointers? Relations. And so on. It ends up helping you understand complex problems even if you're one of those rare people who never ends up touching an actual database.
One could look at it the other way, once you understand OO and pointers, you can understand databases. I think understanding ACID is more important, as you say the concepts from other things will lead to understanding.
And before anyone points out "Language_X doesn't use pointers, don't burden a new coder with them!" you might want to think about how your CPU functions. The language may hide pointers away out of sight, but there is a benefit to knowing how the CPU works. Pointers, 2s-complement, various ways to represent floating point values . . . there is a long list of things hidden out of sight that a good coder should learn about at least in passing. Too many don't, and it always scares me when I see dollars and cents stored as a single float, instead of a fixed point or two integers (take your pick of how many bits, or how to represent sign).
Did you even bother to watch them? They aren't the original episodes, they are reconstructions of the episodes. The audio from most of the lost episodes has been available for a while; I don't know why/how that was saved when the video wasn't. But the reconstruction places that audio with what available video there is and stills from on-set photographs, and publicity photos, and even viewers photos of the tv screen.
So, yes, I can watch Macro Polo, and have. But I saw barely any movement, and half the action was just grunts and shuffling of feet over a still picture; worse than radio shows of the same era!
I missed the video requirement when I first read. A phone with a front video camera is going to be powerful enough to let a kid get into lots of trouble, and download some shady apps. Pre-paid might keep the charges to a minimum, but keeping it virus free? Phones don't have ACLs I'm afraid.
I'm going to skip all the drama-llama posts, and assume you have a good reason and are getting a kid a phone for a good thought out reason. This is tech advice, too many people yell what someone posts 'do my network admin job for me by finding software' are ready to post telling a parent how to do their job. Seriously,/. basement dwellers, you aren't in the OPs shoes, so suck up your uninformed advice and get over yourselves. You don't have a kid? Best way to announce your advice on them is useless.
So why not something that's basically useless for games, internet, etc and is just a phone? Pre-paid flip phone (with the java/flash UI crap, not just a phone book) might still encourage a 6 year old (phones last a while, especially if it's the magic device that lets a kid talk to dad) to do texts and get those nasty java games. And sign up for ringtones and other BS
TL;DR? Jitterbug prepaid. Or one on those child tracker phones that don't have a dial pad, just 3 programmable numbers (usb port or something) and 'emergency' buttons. 6 year old might be bored with those, but for now, but for now, go with the simple and cheap and pre-paid. Then you get to watch the bill and if the time runs out before you put more minutes, then you know someone else is using it/
I wonder if a copper plate over a sacrificial metal might not provide the low amount of copper, corrosion resistance, and price that would benefit all the issues. Still would have corrosion but it would be of your cheaper, hopefully easier to recycle metal while the copper just goes back to dissolve and plate a new piece of equipment.
blister packs of antibiotics? available over the counter, then, I take it? I need to take a side trip and stock up there; going to a drug store during the zombie apocalypse would mean dealing with tweekers and oxy fiends, Are the good strong ones available: geocillin, levofloxicin, linazolid? Any of those with a shelf life of a few years would be a huge addition to a bug-out bag.
Slashdot Mirror
not at all, just playing my post so you could continue further if you wanted. Sometimes a good gag just needs a straight man to continue, guess your's didn't. Would a gay one have been better?
And no, most of the Lampoon stuff was from before my time. The little I've found and read were not enough to cause flashbacks. Now, if I had only been on proper 70's medication, maybe the flashbacks would be more vivid.
Just because the router's log says 'DoS' doesn't mean it is a DoS. The timestamps are the giveaway. A real DoS would look like:
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.227.236.10:443 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 81.22.107.179:56 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 173.208.222.206:80 Saturday, October 12,2013 01:55:05
[DoS attack: ACK Scan] from source: 54.208.162.210:80 Saturday, October 12,2013 01:55:05
Notice how all of the time stamps are the same (i got lazy and copy/pasted. they would also be different ports and hosts in a DDoS but still the same second)? You'd have the log on any home router filled each second if you were being hit with 16 Mbps of ACK scans. Every time you loaded the next page, it would be a different, newer time stamp because the log overflowed. An ACK scan is just another computer punching your IP address into the browser window and asking 'hey, is anyone at this address and port?" (effectively) And yeah, lots of those bots do check common ports like 80 to see if you report back that you have a webserver that they might be able to hijack. And amazon cloud services have made spawning lots of bots pretty easy. But those are scans that are few and far between, and your router spent less than 1ms deciding to chuck each of those packets. And, and ACK packet is generally tiny, next to no bandwidth usage. So think how many other packets could breeze through in the other 999ms of a given second (something like 15.9 Mbps, I think) that a single ACK came at you.
you can wait a few hours, then read the logs and look for stuff during the 'off' time.
The problem with one device running wireshark and other devices all connected to a router is that, by virtue of IP, the wireshark running box won't see the traffic sent to the other PCs. You need to either set up a good Knoppix or Kali Linux boot disc device to act as a pass through, or get a cheap hub, or learn about ARP poisoning to get the traffic to first go to the monitoring box, then get passed along to the target device.
Ideally, Your network would be a very simple DSL modem, not a modem+router. Just a modem or your router reconfigured to bridge mode. Then a hub, yeah, the dumb collision prone boxes are very useful still. Uplink of the hub goes to the modem, and your sniffing box and a good NAT+firewall router get connected to it. Then, behind that NAT and firewall goes your computer. Against, ideally, the sniffing computer will not have requested an IP address, will not even have put it's ethernet port into anything but a passive state. Then you can start up wireshark. After that, start up your machine you think is attracting the attacks. You can sort wireshark traffic by incoming and outbound. And if changing the externally visible IP hasn't helped, you want to look at outbound to see what you are sending to who to get yourself noticed.
I have done exactly this, and it isn't fun or easy, but it did help pass a few Cisco network tests later. Once you get into packet sniffing, and ARP poisoning switches, and packet manipulation of those ARP poisoned packets, you can do all kinds of interesting things. Upsidedownternet doesn't have to be a proxy, it can be done with any switched network if done right. And then, after you graduate from wired networks to sniffing on wireless (and collecting large logs to break keys, or doing deauth attacks on your own gear to see how your modem+router and PC stand up) then you can start in on a whole world of fun and crazy bit-level cleverness.
disclaimer: I've cracked WEP back in the PCMCIA days of having a high speed 802.11b card (custom firmware to go into monitor mode) but it was on my own network or with permission (parents wanted to know how long it would take for a neighbor to borrow their wifi, I remember leaving the linux box running about an hour and a half, but sibling had lots of traffic going). WPA deauth attacks are the same way, don't screw with other people without permission. But once you have permission, go wild; showing my younger sibling their AIM chats when they thought 'the network is encrypted, you can't see me' was a hilarious way to spend my first summer home from college.
The modem side won't have an IP or MAC, it's a layer 1 device, but since it's a DSL router (layer 3 is for routers, you know, IP layer?) it will have both. You know, so the computer can chat with the router at x.x.x.1 or be routed to the other devices in the network by IP? If you have a combined device, and don't have enough access to it's controls to change it's MAC, then get it into a simple Modem mode (sometimes called bridge mode) and hook up a single router that you do control as the first step in the network and feed all traffic through that router. This will, as a consequence of being a simple modem now, make only one of the ethernet ports active and probably/hopefully turn off it's wifi if it has a radio. Then, you really can change your MAC on your router and just hit refresh to get a brand new IP from the ISP.
Now, one thing that hasn't been covered is whether all the traffic is at one port, or across a range or at random. That I noticed, I showed up late to the thread. If your ISP is giving you a NAT address (192.168.x.x or 10.x.x.x or a few others), and you have gotten one port at their outside linked to a certain port inside your network (steaming, gaming, etc) then a DDOS against your ISP could spill over to you every time someone outside tosses packets at the port you are attempting to use.
Lastly, a simple traceroute is still a useful tool. If you get to your ISP's network boarder without very large latency or packet loss, then the problem might be completely external to your network and just leaking in as described above. If you can't even get a ping to the first router beyond your modem, then the OP is being targeted. How? See the other posts.
If you are going to troll in a biology thread, at least go back to the roots of the phrase for the abbreviation? Latin "Panem et circenses" PAeCR1 would at least look like a real gene or protein pathway. Maybe a neuron condition that causes blind following of those one agrees with? But...oh gods, that would mean you would be expressing that gene too!
You must know a lot about those.
I wish we could get rid of this idiotic idea of XX=female, XY = male. Gender and sex are NOT even close to that simple.
It would be nice if people could understand that. Or at least understand that XY genotypes can be born expressing a female phenotype, and vice versa; but getting the general populace to believe anything that goes against what they were taught in school is very tough to do. "If it's that complicated, why don't they teach that?" I've actually heard that, as if a high school advance placement A&P or an on level biology course could get through all of that in less than one term. Sure, it makes Punnett squares easy to understand and relate to personal knowledge, but it's so far from right that it needs to just be tossed out of high school classes completely. "23X0, XXY, XYY, AIS, Turner's Syndrome, and lots of other combinations just make teaching simple 2 gene human expression too difficult. There are so many possible mutations of the genes involved, too many ways for multiple genes to combine like discussed about Down's Syndrome, and too many external genes that also influence human sex and gender (and expression of both and sexuality as well) for it to ever be discussed in the simplified manner needed at the high school level."
Unfortunately, even spelling it out in mostly small words like that doesn't often work. Even getting them to understand that X and Y were picked not because of the shape of the chromosome, which all look like an X during mitosis, but because they were common 'unknowns' in math. When biologists need a new set, they continued with W and Z. "Wiki doesn't say that," results in my face meeting the nearest wall repeatedly, because a facepalm just isn't a strong enough reaction.
Ever seen the Humble Indie Bundles, where GNU/Linux users tend to buy closed source games? I have FTL installed on my A/V workstation, just for those bits of 'brain frozen, working must stop for a few minutes' and it runs just fine. Not exactly an open source game; you might take a look at the Steam library of all the closed source Linux games they support now.
Before the game needs patched? If the game is making calls to OpenGL, then the game doesn't care how the window manager/desktop or the X11/X.org/Wayland/etc handle those calls as long as the version of OpenGL is supported. The only issue will come down to how kernel updates are managed. Too many people punch their package manager for every update, then whine when the bleeding edge kernel isn't supported by the closed-source binary driver for their bleeding-edge graphics card. This is either a problem in the distribution (pushing kernel updates without full support) or the user (updating the kernel without the right binaries available) depending on how you want to look at it. Or to save space, they update a library with a rapidly changing API to the newest version every time a release comes along, and then file bug reports everywhere. If the library isn't stable, then the game devs should force dependency on a certain release, or static link it. And if the user wants to uninstall the library when the game says 'hey, I depend on that' and the package manager allows it? That's back to a distro problem. So it seems like the real problems are average users using bleeding-edge distributions, or stupidly uninstalling things they shouldn't. Hey, I wonder what would happen if I went and uninstalled all those DX patches in SysWOW folders, think everything will still run right afterwards?
Frankly, stabilizing a set of "these files will be available to all games if the OS level is at least at patch version X.Y.Z" seems to be what SteamOS is aiming at. Which would let users do exactly what you say the average users want to be able to do.
As for using Qt on an embedded system, I didn't think you were serious about it. But I've met people who don't look at the specs and think that any library should compile right and do what it's told on any target architecture. So a master of Qt might have a hard time getting the underlying stuff (like the OS, the graphics driver, X.org!) going before moving on to actually running. Worse, think that since their target is an AVR, gcc-avr will be able to tell what syscalls are needed to talk to the other connected devices.
I don't mean to bring down anyone who works at that high level, UI stuff is beyond me for the most part. But it's great fun to sit down with a compiler and write some simple C99 targeting both the ARM9 and ARM7 codes of a Nintendo DS. The homebrew world is pretty good about getting very simple libraries that just do one target thing, but gluing a bunch together isn't always all that good either. Specific to the DS, in 2 screen mode the ARM7 is the chip that has to talk to the audio chip, the ARM9 can just send it signals on what it wants done, while the 7 has to get coded to do that. So a demo might use the 9 to do most of the work, and call a playNote(freq, duration, ...) that the 7 runs and passes to the audio. But if you don't know the wireing, and try to run your audio straight from the 9, nothing works. If you write all your code in the 9 and then pass each individual unstruction as setDACfreq(freq) and setDACduration(duration) and then play(), you've just locked the 9 and the 7 cores up for 3 function calls instead of 1, and the available cycles to draw, compute AI and game engine stuff, will be delayed for 3 times as long. The first take the 9 one function, the 7 a single response and passing that along to the audio chip (inline function? or a simple movement of all music the the 7's memory and the 9 just sending a playNow(songArrayName) that doesn't wait for a return, and then both can do back to doing other parts of the demo, while the 7 waits for the timer interrupt to say 'next note now'. And the graphics calls on that system . . . sheesh! The early libraries were mostly text and interface reads.
To do that at the high level only, without going into the lower details, requires a big library that might not exist on your target yet. So a new coder can wait, and the good coder can at least piece together a hacked up library while they wait for the great embedded gods to create a really good library or OS. Personally, I'm not that patient to go through all the spec sheets and testing bus lines, but am comfortable piecing together a hacked up library to do what I need to get done. I'm not going to write the first 'print text to screen' library, but from that and someone else doing the probing and explaining it in simple detail (this chip uses syscall2 to do...) I can cobble together what I need to get my projects underway. I know, that requires a library of sorts to get those syscalls out to the programmer and the compiler to have the right target abilities; all the levels above that is where I'm comfortable with my code. But that knowledge of the caveats and gotchas that pop up and are usually in the original documentation from the folks doing that first gcc port, and knowing how to apply what those docs mean when they reference the buses and chip capabilities and flaws is an important skill.
Something that many "glue together libraries and other peoples demo code" coders I know don't do. They tend to be so agnostic to the hardware that I've seen (C++ time now) a pointer set by a call to new() that wasn't in the initializer of the class but in a private function called when the object appears in view (and doesn't check that it wasn't already initialized) and then also failed to check that new returned a non-null value before dereferencing it. And finally ends with delete() in the destructor and finishes with setting the pointers to 0 (architecture dependency again, 0 isn't always null, and it isn't always memory location 0x0 either, but it was in the destructor
VHDL is . . . writing a document to generate a circuit board, IMO. Really, you should be able to take most VHDL that use common components (4xxx CMOS or 74xx TTL) and get the output as a schematic. It may be that FPGA and other VHDL-targets are cheaper and more well stocked with the obsurca of devices (DAC, ADC, timer and PLL timer mux or dividers, and so on) than a cabnet full of hard epoxy ang glass and copper IC components, but a bus is just a wire on a breadboard or a trace on a circuit board. Granted, the VHDL to schematic won't add and do the routing to get equal length traces (without compiler support, I would expect), or place the needed chokes and caps to maintain a good power supply or audio (no VHDL targets I've used required me to think about those parts), or know which diode to use to drop anything over 0.8v to 0.6 (audio 1v to -1v AC for audio distortion) but you could hook up with a parts library and get all the parts you'd need.
I suppose thinking like a VHDL writer does make doing shaders easier, since it's all parallel operations. But shaders are image processing for the most part. Or obfuscating a problem to look like image processing (assuming you aren't using shaders as part of OpenCL or something and your code is actually the normal code just compiled into shader functions...the compiler and library doing to obfuscating for you). Going the other way, from shaders to VHDL, you'd still need to know the hardware parts and how to make your code do very simple steps. Or maybe that's Verilog, I get the two syntaxes confused all the time.
Since the article was about useful ideas, I think knowing a simple assembly language is still a good thing to pick up. It doesn't have to run in anything other than an emulator that even allows for non-standard instructions like 'print out what's in register X' so you can tinker. C doesn't expose all the flaws that show up at the embedded level, because the compiler can hide them away behind the base libraries. The transistor level I leave for computer engineers instead of programmers; it's useful to know about pipelines, and if you are doing embedded programming you need to know how many instructions deep and how the jump prediction works, but you don't need to worry about the electron propagation like the engineers do.
And I disagree that all programming is being done at a high level now. Look at the way people build modchips for consoles, break HDCP encryption, and even the console designers who have to put together the OS and all the embedded programmers who are adding drivers for graphics chip X or radio chip Y to the latest Android/Windows/iOS device. They are programmers, the banking DBA who throws together a system where your account balance is a floating point and chucks that to a webpage isn't - in my book. You could be a good programmer without understanding things below the JRE, or you might not be. It'd be hard to tell, and it would vary so wildly from the coder who just knows how to glue together other libraries without checking that the functions returned a non-error value to the one who understand enough to know what's going on below the JRE level but just hasn't learned it yet.
A good compiler, as pointed out elsewhere in this discussion (look for lisp and closures) can be implemented in very few steps for the right language, and still be complete and usable.
You mean like Heapsort? One of those algos that most computer science programs still require you to write, just to prove you understand how to implement a heap?
Teaching the concept doesn't have to be the same as 'just teach the concept', You can do a puzzle with recursion, like Towers of Hanoi. Start them with a physical model, then keep adding rings. Let a kid figure out how adding a new ring increases the number of steps to solve it much faster than the ring before did. Ta-da, recursion and Big-O complexity, without actually bringing up either one. If the kid gets interested enough to grab a book on programming, then some of the basic stuff is already grounded in a real concept and they'll have a better understanding of it. Then again, I had a great computer teacher from 4th grade through 7th who taught like that on some shiny new Apple ][ and an occasional C64. Asked her years later why she taught us like that, and how it had helped me jump ahead in college. It was because she didn't know how to program at all, the computers were a gift to the school, and so she just gave us puzzles that could be solved without a computer and that it amazed her how kids could pick up the technology to solve the problems. Apple Basic was easy enough to read, and she forced comments and writing it on paper first, so she could see that we understood the problem and weren't just throwing random things until something worked.
Bonus to the Towers problem: does where you put the smallest ring determine where the final tower will be? How, and why?
Well, in C++, since an array is just a pointer behind a layer of language obfuscation . . .
That being said, if you master every aspect of Qt5 including QML and using network and databases, and development for different mobile devices, while also embracing the functional aspect of JavaScript (for QML and HTML), you should be pretty well set for everything on every platform ;-)
Except embedded systems with multiple parallel data buses between different architecture chips, like an average handheld game device or a phone. You could flounder, trying to get Qt5 to run on it or any other library of your choice when the OS hasn't been finished yet. But you'd probably end up with something that barely runs and at a pace that makes snails stop and feel pity. And sometimes building those libraries from scratch is the job, and if you are used to using something as big at Qt to handle stuff for you, you might not be able to manage the tasks that it obfuscates.
Knowing how the CPU works can be a big help. I've seen coders who don't know how a floating point value or operation take place; which leads to them not knowing why adding 1,234,567,891,011.12 to 0.01 can end up different if you reverse the order of the values. It leads to not knowing why 127+1 rolls over to -0 instead of -1 on certain architecture. And it leads to not knowing why a pointer works, even if the pointer is abstracted behind a language that is effectively interpreted into C before being compiled to object code. Or what jobs the compiler and linker are actually doing, should the language of choice require them.
And with so much effort going into embedded systems, you can write your code in what ever high level language you choose, but you better understand the underlying architecture. And learning something simple (MIPS 1 or the Acorn RISC machine ARM2), and early, can let you pick up the harder stuff later while understanding the concepts that you just couldn't manage without.
Also, once you understand databases conceptually, everything starts to look like a special case of a database. This is a good thing. C data structures? Table records. Pointers? Relations. And so on. It ends up helping you understand complex problems even if you're one of those rare people who never ends up touching an actual database.
One could look at it the other way, once you understand OO and pointers, you can understand databases. I think understanding ACID is more important, as you say the concepts from other things will lead to understanding.
And before anyone points out "Language_X doesn't use pointers, don't burden a new coder with them!" you might want to think about how your CPU functions. The language may hide pointers away out of sight, but there is a benefit to knowing how the CPU works. Pointers, 2s-complement, various ways to represent floating point values . . . there is a long list of things hidden out of sight that a good coder should learn about at least in passing. Too many don't, and it always scares me when I see dollars and cents stored as a single float, instead of a fixed point or two integers (take your pick of how many bits, or how to represent sign).
Did you even bother to watch them? They aren't the original episodes, they are reconstructions of the episodes. The audio from most of the lost episodes has been available for a while; I don't know why/how that was saved when the video wasn't. But the reconstruction places that audio with what available video there is and stills from on-set photographs, and publicity photos, and even viewers photos of the tv screen.
So, yes, I can watch Macro Polo, and have. But I saw barely any movement, and half the action was just grunts and shuffling of feet over a still picture; worse than radio shows of the same era!
I missed the video requirement when I first read. A phone with a front video camera is going to be powerful enough to let a kid get into lots of trouble, and download some shady apps. Pre-paid might keep the charges to a minimum, but keeping it virus free? Phones don't have ACLs I'm afraid.
I'm going to skip all the drama-llama posts, and assume you have a good reason and are getting a kid a phone for a good thought out reason. This is tech advice, too many people yell what someone posts 'do my network admin job for me by finding software' are ready to post telling a parent how to do their job. Seriously, /. basement dwellers, you aren't in the OPs shoes, so suck up your uninformed advice and get over yourselves. You don't have a kid? Best way to announce your advice on them is useless.
So why not something that's basically useless for games, internet, etc and is just a phone? Pre-paid flip phone (with the java/flash UI crap, not just a phone book) might still encourage a 6 year old (phones last a while, especially if it's the magic device that lets a kid talk to dad) to do texts and get those nasty java games. And sign up for ringtones and other BS
TL;DR? Jitterbug prepaid. Or one on those child tracker phones that don't have a dial pad, just 3 programmable numbers (usb port or something) and 'emergency' buttons. 6 year old might be bored with those, but for now, but for now, go with the simple and cheap and pre-paid. Then you get to watch the bill and if the time runs out before you put more minutes, then you know someone else is using it/
I wonder if a copper plate over a sacrificial metal might not provide the low amount of copper, corrosion resistance, and price that would benefit all the issues. Still would have corrosion but it would be of your cheaper, hopefully easier to recycle metal while the copper just goes back to dissolve and plate a new piece of equipment.
blister packs of antibiotics? available over the counter, then, I take it? I need to take a side trip and stock up there; going to a drug store during the zombie apocalypse would mean dealing with tweekers and oxy fiends, Are the good strong ones available: geocillin, levofloxicin, linazolid? Any of those with a shelf life of a few years would be a huge addition to a bug-out bag.