Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/06/2017 in all areas

  1. Have new build generated by ProxHTTPSProxy (Rev2b), with small changes sript so with more simultaneous connections the proxy does not come to timouts, various python modules updated and the config.ini supplemented by some entries. If anyone has interest please write a PM to me.
    2 points
  2. For all those who still use Google Chrome, I would like to provide a small updater for updating the PPAPI Flashplayer. If interested of Google Chrome version 49.0.2623.112 with updated components please PM. Download here Password: 2P&n6KVb1%vA7$eCja5D$hU3B1YvJM9Z4zI9Trz§
    1 point
  3. The .iso loading function seems to work OK for \sources\install.wim, but is does not work on ISOs containing .esd files. Can it look for \sources\install.esd inside ISO files please? Some Microsoft ISOs contain both 32-bit and 64-bit Install.esd files, so it also needs to look for \x86\sources\install.esd and \x64\sources\install.wim (and then ask which one you want to use) Thanks!
    1 point
  4. Posted today on ZaufanaTrzeciaStrona.pl facebook page. (they are polish guys providing some IT security services and training, also keeping up good website with news and articles about that FYI)
    1 point
  5. @NoelC and @Mcinwwl yes and no: AMD Bulldozer's architecture uses Clustered Multithreading and has these things called "clusters" which it uses to process stuff. These clusters have two integer (aka ALU) units, one floating point unit (aka FPU), and share an execution engine (aka EX, the "do stuff" part). This basically makes the "cluster" (aka "core") equivalent to a dual-core processor in integer math, and a single-core processor in floating-point math. Now, having double the APUs is great for heavily multithreaded applications and there is a measurable advantage in certain types of applications. Anyway, the Bulldozer "clusters" share FPUs and L2 caches, and this causes single-threads to process slower since they have to "wait" for shared resources (aka serial, or in-order, processing). Hence, Bulldozer "clusters" have slower single-threaded performance as they get stuck in the queue. The Nehalem (Intel) architecture and its children use Symmetric Multithreading, which uses two identical logical processors per "core" - similar to an AMD "cluster," but with 100% of the same resources available to both processors. Each "core" has the equivalent of dual-core APU and dual-core FPU resources, and also shares an execution engine. But, since the processors in the "core" do not share resources in the same way as Bulldozer, it doesn't get stuck waiting for stuff to do. Let's suppose you have an 8 core/cluster AMD and a 4 core/8thread Intel. Your operating system really only sees 8 logical processors when it has to assign threads, so it assigns 1 per cluster, even though the cluster can really do two threads (if they're integer math). When things get stuck, this pretty much makes each "cluster" half the FPU performance of an equivalent Intel "core" and reduces the ALU performance advantage. Intel is faster per "core" in single-thread performance than AMD "clusters" due to their architectural differences. Additionally, Intel's improvements to their execution engines and resource scheduling have caused their 4 "core" (8 thread) processors to eliminate the advantage of 8 "cluster" processors in multi-threaded performance. Fortunately, AMD is abandoning clustered multi-threading in favour of simultaneous multi-threading (like HyperThreading on Intel). In other words, AMD processors have to "wait a lot" for shared resources in single-threaded applications, Intel processors don't, and even though threads are assigned by the OS, the threads a CPU shows to the OS and the way it shares resources across cores are a key point for single thread application. That's pretty much it and sorry for the wall of text.
    1 point
  6. No, it didn't. You should take some time to learn how to critically read *any* statistical data. Variations within +/- 1% or -more likely - 2% represent only the possible error in the sampling or data collection. jaclaz
    1 point
  7. Once I tried running a virus on Windows 2000 SP4 (I think I also had BWC's kernel32 extension) and every single virus failed xD Not ONE out of 60+ viruses it attempted to install worked! Missing dependencies and windows version check was too much for it Most virus writers want to do as little work as possible, they're not gonna bother with legacy systems
    1 point
  8. Guimenez, there are other sites that explain how to do that, but even then: I would not advise to make updated iso/wim/esd files anymore. Here are my reasons: (1) For windows 10, there are only 3 updates you need, wether you install from an "old" or a "new/ updated" iso. You only need the latest Cumulative Update, one other update, and maybe Flash update. In the old days, an "old" source file would need more updates than a newer source, but with Cumulative updates, that's a thing of the past. (2) Better wait for next week anyway: There will be a new "Windows 10 1607.1" esd directly from microsoft. So that's version 1607 (july 2016), "with update".
    1 point
×
×
  • Create New...