481 karma · joined September 9, 2021
Please see my HN profile for contact info in order to prioritize your interview process.
Hiring L5,L6,L7 software dev engineers!
Degree in Computer Science, Engineering, Mathematics or equivalent experience · Programming experience with at least one modern language such as Java, C++, or C# · Good written and verbal English communications ·Strong analytic and problem solving skills
PREFERRED QUALIFICATIONS Experience building high volume web services . Experience building highly available systems . Experience with distributed systems . Working knowledge of Hadoop, MapReduce, or other Big Data processing platforms
Job summary
Amazon Web Services (AWS) is looking for talented software engineers who have a passion for Big Data and distributed systems at trillions of transactions scale to help build the next generation of AWS internal services. As a foundational system we scale with the growth of cloud computing at Amazon. The AWSBilling team is responsible for Metering Usage and Generating Monthly Charges. These include but are not limited to enabling: AWS product pricing, AWS product subscriptions, AWS product discount programs, customer credit management, storing AWS product usage, computing the bill, the estimated bill, computing tax, and storing bills and line items for external customer consumption.
As a Software Developer, you have the opportunity to lead the paradigm shift in streaming Big Data by building applications on top of cutting-edge AWS technologies such as Kinesis, EMR, DynamoDB, Redshift, Aurora, and many more. Additionally, you can build meaningful software that can radically change how AWS wins our largest customers over to the Cloud.
Work/Life Balance
Our team puts a HIGH value on work-live balance. It isn’t about how many hours you spend at home or at work; it’s about the flow you establish that brings energy to both parts of your life. We offer flexibility in working hours and encourage you to find your own balance.
Please note this position requires working onsite in Seattle or NYC 5 to 8 days per month. Minimum 5 days.
https://github.com/1stOctet/YouWillUnderstandWhenYouAreOlder...
Fing helps you get the most of your home network. See all the devices connected to your WiFi, run network scanners, monitor your Internet speed and security level. Discover our free app, available for both PC and Mobile.
README…
It's basically a fail2ban for windows. Its goals are also mainly what we love about fail2ban:
pre-configured no-initial-ducking-around-with-scripts-or-config-files install-and-forget You can download it here ( v2.1.5 - April 2022 ) .
Also, we love issues!
If anyone needs something or has questions about something, please feel free to open an issue. We are especially happy to get issues about log-entry samples we don't react on, or ideas of how we can support more protocols.
A bit more detailed description of what EvlWatcher does.
Scenario: there are those bad people out there, hammering your service (RDP and whatnot) with brute force attempts.
You can see them and their IPs clearly in the Windows Event-Log.
You have searched the web and yea, there are plenty of tools, scripts, and all that, to read the event-log and automatically ban the attackers IP.
You however, are lazy. You need something like fail2ban, with a preconfigured set of rules to just RUN right away and it works.
But then, it still needs enough flexibility for you to completely configure it, should you wish to do so. EvlWatcher does that. It scans the Windows-Event-Log, and reacts.
It works by installing a service that scans the event log for unsuccessful login attempts. When one of its rules are violated (e.g. trying to log in without correct credentials, more than 5 times in 2 minutes), it will place that poor bastard into a generic firewall rule, and thereby ban the attacker for 2 hours.
Also, when someone is repeatedly trying, there is a permanent ban list for that, where people defaultly land on when they've had three strikes.
You can, of course, adjust the rules to your liking. They are basically a consisting of an event source, and a Regex to extract an IP, its pretty simple.
The experiment
Over the Spring 2009 semester two Berkeley undergraduates, Priscilla Ku and Janet Larwood, undertook to do the required 40,000 tosses. After preliminary experimentation with practical issues, there was formulated a specific protocol, described in detail below. Cutting to the chase, here is the complete data-set as a .xlsx spreadsheet (see sheet 2). This constitutes a potentially interesting data-set in many ways -- one could compare numerous theoretical predictions about pure randomness (lengths of runs, for instance) with this empirical data. For the specific question of dynamical bias, the relevant data can be stated very concisely
of 20,000 Heads-up tosses (tossed by Janet) 10231 landed Heads
of 20,000 Tails-up tosses (tossed by Priscilla) 10014 landed Tails
Btw, I tried everything to solve this without Adderall. For over the counter I recommend L-tyrosine but careful with potential anger side affects.
Edit, active cyclist. Category 3, sometimes win races.
One thing I hope to see in the future is a better product filtering experience. When I worked on a jquery product filter I realized the DOM bloat was the main problem.
I wonder if D1 can help devs build instant product filtering pages that don’t require the reload like microcenter or Newegg does.
To set a cookie, you just have to add it to the response the server sends back after requests. The browser will then add the cookie upon receiving the response.
https://stackoverflow.com/questions/17769011/how-does-cookie...
OP link on another site. Original source? https://ciderware.com/sites/default/files/jamaoncology_gupta...
Once you can add small changes like print statements it becomes yours to control and slowly understand.
Step two is multiplying the amount of hours needed by a factor of 10 or 100. Don’t underestimate the time needed to start understanding. Biggest mistake many mortals make.
Nothing in your analysis shows this. Moreover unless you explicitly deployed a root certificate on your clients (or if an app on the client did it), the router can't decode TLS traffic (deep inspection) without you getting certificate warnings on the client. In that case, the only thing the router can see is the dns request, the IP and the TLS SNI. In short your title is misleading.
permalinkembedsavereportreply [–]ArmoredCavalry[S] 11 points 14 hours ago*
I agree they couldn't be inspecting the contents of your traffic over TLS, but they could easily view destinations. I also agree, there's nothing in my analysis that proves that all the requests are related to network traffic. However, if you look at the wording of the reply (directly from TP-Link) to XDA in their review, I don't see how it could be interpreted any other way? Regardless, I probably should have made my title "appears that it may send traffic related data". I'll be happy if that isn't the case, but the lack of clear explanation from TP-Link when I've contacted support leads me to assume the worst
permalinkembedsaveparentreportreply [–]2fast2fourier 4 points 12 hours ago I think it's best not to write something that damaging without proof, especially when most people only read titles. Saying they're sending metadata and violating your privacy is all you'd need to hear.